Оло Ло

а ещё мне например не хватает вот такого сервиса — видео+вики

загружаешь видео, ставишь закладочку - и пишешь, на отметке 01:05:22 докладчик затронул такой то пункт рассказа.

И чтобы можно было так всё разметить.

И чтобы это было коллаборативно.

И чтобы потом по полученным отметочкам можно было навигировать беспроблемно. И к ним дописывать конспект увиденного.

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

А хочется как-то так, чтобы это было публично.

dotsub.com тоже как-то с этим не очень справляется, там нет навигации через субтитры. то есть можно вроде как коллаборативно нафигачить субтитры к видео, но нельзя щелкнуть по временной отметке в скрипте и перенестись на неё.

Да и не для этого он предназначен.

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

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

upd2. а вот шняга про коллаборативное видео, нашел тут в процессе.
http://www.kaltura.com/devwiki/index.php/Main_Page
http://wikieducator.org/Help:Collaborative_video
http://wikimediafoundation.org/wiki/Collaborative_Video

А вот например, что меня волнует.

Меня волнует как должен выглядеть софт (для машин - программы, для людей - игры-правила (они же — практики и процессы)), который способствовал бы аутентичному, искренному, честному поведению.

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

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

В ХР 1.0 (которое я нежно люблю) 12 практик, но внедрять можно не все сразу, а понемногу.
На первых порах можно внедрять не все, а например штуки по три:
— TDD+refactoring+continuous integration например. Или
— pair programming+coding standards+collective code ownership. Или
— planning game+on-site customer+small releases.
— и так далее. На самом деле сочетать можно как угодно, возможных сочетаний из 12 по 3 — 220 штук и все в принципе хорошие.

Если взять вот так всего три практики из референтного описания в книжке Кента Бека, то всё равно у тебя будет работоспособная целостная человеческая система разработки софта. Если добавить четвертую — будет тоже работоспособная и целостная. Если внедрить только две — тоже будет ок.

Про это явление на последней встрече AgileRussia сказали, что «ХР-то ведь обладает фрактальной структурой, что вы хотели?»

Вот меня и волнуют такие фрактальные архитектурные описания. Как сделать такую же крутую систему как ХР, но только не для бизнеса по разработке софта, а например для бизнеса в сфере хлебопечения? Сразу отбрасываем возражение «нельзя выехать на одной практике "замеси тесто"». Это практика более низкого уровня, точно так же как бизнеса нельзя построить из практики "запиши алгоритм в виде функции на Си".

Мне кажется, что такие архитектурные описания становится возможным записывать, только тогда, когда достигнешь определенного уровня честности с самим собой. Например Кент Бек признался себе — я не пишу идеальный код без багов с первого раза, нужно чтобы был критерий, по которому можно проверять. И появляется требование «как бы нам проверять код на баги?», потом происходит какой-то дискурс (magic! креативное брожение и блуждание в потемках в поисках способа через получение разного опыта и его осмысление) и потом придумывают практику TDD.

А потом Кент Бек снова признался себе — программисты, да и я сам такой, часто отвлекаются или наоборот зависают и тупят в процессе написания кода. Человеко-час — мифический, он всегда умножен на велосити, которая всегда меньше единицы, а часто и меньше одной второй. Надо как-то не терять фокус, поставить надсмотрщика что ли. Но как сделать, чтобы надсмотрщик был приятен, а не фрустрировал?
А может быть даже — помогал??? А ведь помощник будет тоже следить и не давать терять фокус, правда? Но будет мешать вопросами тупыми, если он более слаб по квалификации? Значит партнер что ли? Не подмастерье, а коллега? Ну и дальше парное программирование как решение, которое потом начинают защищать от критики, показывая что плюсы от не потерянного фокуса и сохраненной простоты решений (повышения индивидуальной велосити) превышают минусы (якобы уменьшение ресурса человеко-часов вдвое) Было два чувака с велосити по 0.3, в сумме 0.6, а стала одна пара с велосити 0.8, синергия ололо.

Ну и так далее.

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

--
Ах, да. Собственно об аутентичности.