Здравствуйте, DarkGray, Вы писали:
ЗХ>>Хотелось бы репозиторий кода, основанный на принципах Wikipedia.
DG>в чем отличие, от http://sourceforge.net, например?
гхм... вроде объяснил уже
1. единица информации — не библиотека, а кусочек кода, который можно охватить взглядом.
2. сниппеты может править кто угодно в любое время.
DG>допустим Codepedia уже есть, какие кусочки кода ты хотел бы там видеть?
Вот это уже по делу вопрос.
В теории — те, которые соответствуют (1) — лаконичные решения повседневных задач. Сверхцель — чтобы, как только у меня возникает некая "типовая" задача (типовая == с большой вероятностью, эту задачу уже неоднократно решало великое множество программистов) наиболее естественной мыслью было бы — пойду возьму codepedia.
На практике... Т.е. чтобы примеры привести... Вообще, надо в rsdn.src покопаться но в общем:
* простые абстракции — математические, баз данных, регекспов, и т.д. и т.п.
* платформ-специфик вещи: скажем, простенький код для работы с tray icon или hook...
...ммм... чего-то такое.
(Вообще говоря, часть буста стоило бы раздербанить на такие вот "сниппеты" — это просто другой подход, не "большая библиотека, в которой есть все — стоит только заинклудить", а "место где можно взять типовой код решения такой задачи, вылизанный до белизны")
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>Хотелось бы репозиторий кода, основанный на принципах Wikipedia. ЗХ>А конкретно, на важнейшем ее принципе: любой кусочек информации может править любой человек. ЗХ>Мне кажется, что это дало бы (по аналогии с той же Wikipedia) итеративно улучшаемые (в пределе — идеальные) самостоятельные тематические кусочки кода.
Посмотри вот это: http://ru.livecode.org/index.php/Заглавная_Страница
— человеком двигали вполне благие намерения. И движок там от Википедии (Медиавики). А получилось черти что. А все почему? Потому что (i) не надо распыляться и пытаться охватить все на свете и (ii) очень важна грамотная классификация/категоризация.
Здравствуйте, DarkGray, Вы писали:
DG>>>Структуризации — нет, ЗХ>>Ну, вообще-то категории там есть. DG>категории — это лишь один из инструментов структуризации
а какие нужны еще?...
DG>>>поддержки нескольких точек зрения — нет, ЗХ>>Мммм... Мне кажется, для энциклопедии правильный подход — именно используемый в Википедии NPOV (Neutral Point Of View) DG>В идеале — да. DG>но на горячие (на flame-овые) темы — обычно NPOV не бывает.
горячие головы можно остудить баном или запретом редактирования статьи...
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>В теории — те, которые соответствуют (1) — лаконичные решения повседневных задач. Сверхцель — чтобы, как только у меня возникает некая "типовая" задача (типовая == с большой вероятностью, эту задачу уже неоднократно решало великое множество программистов) наиболее естественной мыслью было бы — пойду возьму codepedia.
ЗХ>На практике... Т.е. чтобы примеры привести... Вообще, надо в rsdn.src покопаться но в общем: ЗХ>* простые абстракции — математические, баз данных, регекспов, и т.д. и т.п.
Имхо, такие вещи должны входить в стандартную библиотеку языка. В Java, .Net, Python, Perl, Ruby так и есть. Это просто исторически так сложилось, что у C/C++ со стандартными библиотеками беда.
ЗХ>* платформ-специфик вещи: скажем, простенький код для работы с tray icon или hook... ЗХ>...ммм... чего-то такое.
ЗХ>(Вообще говоря, часть буста стоило бы раздербанить на такие вот "сниппеты" — это просто другой подход, не "большая библиотека, в которой есть все — стоит только заинклудить", а "место где можно взять типовой код решения такой задачи, вылизанный до белизны")
По поводу раздербанивания boost-а -- это
А вот Ruby community себе подобные вещи сделала: RubyGems и RAA — Ruby Application Archive. Правда поиска по исходникам там нет, но вот идея у RubyGems здравая -- можно загрузить тот пакет, который тебе нужен. При этом RubyGems проверит и, при необходимости загрузит, нужные зависимости, автоматически запустит unit-тесты, сгенерирует RDoc-документацию (аналог Doxygen и JavaDoc).
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
В связи с этим прокомментирую ваши мысли:
ЗХ>Единица хранения ЗХ>Один snippet — это некий набор единиц языка (классов, функций), не зависящий от сторонних библиотек (кроме стандартной библиотеки данного языка), служащий однозначно формулируемой цели, и могущий быть использованным "как есть", без переделки.
IMO, Snippet не должен быть больше одной функции по размерам. Ни в коем случае не C++-проект, как на CodeProject!!!
Все, что больше одной функции — называется "библиотекой" и должно удовлетворять всем требованиям библиотеки.
ЗХ>Поскольку однозначного имени (по которому любой программист его найдет) snippet'у дать нельзя, ему дается краткое описание и набор тегов (соответственно, поиск сниппета на сайте — отбор по тегам).
IMO, описание должен исправлять только модератор, набор тегов — любой желающий (с постмодерацией).
ЗХ>Редактирование snippets ЗХ>Редактировать сниппет может кто угодно.
IMO, редактировать сниппет должен создатель (прочитав комментарии) или модератор, или доброволец, при необходимости. ЗХ>Для редактирования сниппета сайт должен предоставлять полноценный редактор кода (подсветка, автоотступ, сворачивание веток, autocomplete стандартной библиотеки).
Последнее требование сводит на нет возможность реализации в обозримом будущем всей затеи.
Возможно, лучше было бы автовыравнивание по выбранным стандартам кодирования при отправлении кода. ЗХ>Необходимо ввести сниппет и юнит-тест на него (код выполняющий проверку корректности сниппета и одновременно — демонстрацию его возможностей).
IMO, юнит-тесты в случае "snippet порядка размера функции" не нужны вообще — ведь любой может откомментировать snippet и указать его ошибки и на что исправить этот код. ЗХ>После этого сервер выполняет проверку.
На хостинге компиляторы размещать? ЗХ>Проверяется: синтаксис и компилируемость кода, стиль (на сервере существуют некоторые правила, типа длины имен переменных и прочая); выполняется юнит-тест. Результатом выполнения юнит-теста является список тестов, которые код прошел/не прошел, а так же (в идеале) покрытие кода тестами (какие классы/функции в выполнении юнит-теста задействованы не были). ЗХ>Код, не прошедший проверку на компилируемость, запостить нельзя. Код, не прошедший критические тесты, запостить нельзя. Код, не прошедший некритические тесты, запостить можно, в каталоге он будет показан как "сниппет такой-то — проходит 80% тестов".
Это был план развития сайта на следующие 10 лет
А вот из того, что можно быстро осуществить — это рейтингование snippets и возможность рейтингования комментариев как "важных".
IMO, комментарии обязательны и желательно должны быть древовидными. Из-за линейности комментариев и присутствующего там флейма и оффтопика потом ничего не разобрать. ЗХ>Поиск и выбор snippets ЗХ>Поиск идет по тегам и просто через поисковую систему. [далее пропущен тяжелоосуществимый бред]
IMO, хороший поиск и индексирование сайта поисковыми системами обязательно.
Также обязательным является кластеризация. Она не обязательно должна быть навороченной, главное, чтобы она стремилась к тому, что один snippet попадал в одну категорию. Так, для начала разделов 5 будет вполне достаточно.
В этом плане юзабилити koders.com и ru.livecode.org очень низкое, что и определяет степень их использования разработчиками. Сайт, который будет активным, должен быть открытым и для поисковиков.
Обязательно должна быть возможность прийти на сайт из интернета, набрав в поисковике нужный запрос, и попасть сразу на страницу примера. Пример: поищите в google "php open file" — наглядный пример, как все должно работать.
Еще пример. RSDN подкачал. Пример: поищите "rsdn getdllversion" или "site:www.rsdn.ru getdllversion" — и где тут сообщения могучего форума RSDN по данной теме? Более того, отмазка "ищите в поиске на rsdn" оказывается неконструктивной. Я пользуюсь каждый день как минимум десятком сайтов. Стоит ли мне запоминать, в каком месте на каждом сайте расположен запрос поиска, и потом мучиться с его убогой, или просто особенной сортировкой в результатах выдачи? (Честно говоря, именно из-за плохого поиска и появляются сообщения, которые уже на 20 раз обсуждались — человеку проще задать вопрос, чем найти его)
ЗХ>Административное устройство ЗХ>По всей видимости, кроме модераторов (чья функция — как всегда — пресекать хулиганство и вандализм) нужны maintainers (добровольцы-энтузиасты), которые станут более-менее регулярно просматривать новые и измененные сниппеты, выбрасывать никому-не-нужные, рефакторить плохо-написанные и т.п.
IMO, maintainers — это и есть модераторы, а твои модераторы — это администраторы...
ЗХ>На закуску — проблемы реализации ЗХ>Крутейшая среда с рефакторингом и веб-интерфейсом, серверная, выдерживающая дикие нагрузки — это не шубу в трусы заправить. Других проблем не видать Возможно, нагрузку можно каким-то образом перенести на клиента (скачивается программа, в которую уже встроен редактор; каким-то образом полагаться на установленный у клиента компилятор, и т.п.). JetBrains, ау?!
Это был самый настоящий бред. Советую поискать бритву Оккама, она должна у вас быть где-то поблизости.
IMO, форма с подсветкой кода и автовыравниванием после нажатия кнопки "preview" будет смотреться замечательно.
А легкий submit без обязательной постмодерации (но только для зарегистрированных пользователей!) — необходимое условие для быстрого пополнения сайта.
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>1. единица информации — не библиотека, а кусочек кода, который можно охватить взглядом. ЗХ>2. сниппеты может править кто угодно в любое время.
Здравствуйте, AndrewVK, Вы писали:
ЗХ>>1. единица информации — не библиотека, а кусочек кода, который можно охватить взглядом. ЗХ>>2. сниппеты может править кто угодно в любое время.
AVK>Простой вопрос — а чем это отличается от VCS?
Ну, если по всему этому топику непонятно — то я не знаю как объяснить.
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>>>1. единица информации — не библиотека, а кусочек кода, который можно охватить взглядом. ЗХ>>>2. сниппеты может править кто угодно в любое время.
AVK>>Простой вопрос — а чем это отличается от VCS?
ЗХ>Ну, если по всему этому топику непонятно — то я не знаю как объяснить.
Нет, непонятно. Все, о чем ты говоришь, реализуется нормальной VCS + стандартом на метеданные кусков кода + возможно специализированным клиентским софтом. По любому удобнее wiki.
Здравствуйте, Зверёк Харьковский, Вы писали:
AVK>>....По любому удобнее wiki.
ЗХ>Ты вообще отвергаешь идею вики? (не для редактирования кода, а в целом)
Идеологически разницы между wiki и VCS + публикатор нет. Однако VCS обеспечивает куда больше сервиса, да и редактировать на локальной машине проще.
Здравствуйте, AndrewVK, Вы писали:
AVK>>>....По любому удобнее wiki.
ЗХ>>Ты вообще отвергаешь идею вики? (не для редактирования кода, а в целом)
AVK>Идеологически разницы между wiki и VCS + публикатор нет. Однако VCS обеспечивает куда больше сервиса, да и редактировать на локальной машине проще.
Мммм... Разница, имхо, все же есть.
Юз-кейс vcs: засасываем на локальную машину весь проект, работаем с ним, закидываем на сервер обновления.
Юз-кейс wiki: бродим по содержимому сервера, рассматриваем его, если что-то "не понравилось" — выполняем in-place редактирование.
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>Мммм... Разница, имхо, все же есть. ЗХ>Юз-кейс vcs: засасываем на локальную машину весь проект, работаем с ним, закидываем на сервер обновления.
1) Совсем не обязательно весь.
2) Для просмотра вобще не надо ничего явно засасывать (см. например RepoBrowser в Subversion, или то, что кажет SVN-сервер по http-протоколу, есои зайти браузером)
ЗХ>Юз-кейс wiki: бродим по содержимому сервера, рассматриваем его, если что-то "не понравилось" — выполняем in-place редактирование.
Все то же можно сделать и в случае VCS, вопрос в инструменте. Браузер в любом случае очень плохо подходит для редактирования кода (его как минимум один раз нужно скомпилировать и запустить).
Здравствуйте, AndrewVK, Вы писали:
ЗХ>>Юз-кейс wiki: бродим по содержимому сервера, рассматриваем его, если что-то "не понравилось" — выполняем in-place редактирование.
AVK>Все то же можно сделать и в случае VCS, вопрос в инструменте.
Тогда это будет wiki, реализованная поверх VCS Насколько я помню, такие штуки где-то видел
AVK>Браузер в любом случае очень плохо подходит для редактирования кода (его как минимум один раз нужно скомпилировать и запустить).
Если внимательно почитать исходное сообщение, там это учтено.
DG>>>>Структуризации — нет, ЗХ>>>Ну, вообще-то категории там есть. DG>>категории — это лишь один из инструментов структуризации
A>а какие нужны еще?...
Отношение частное — общее,
отношение целое — части,
порядковые отношения,
и т.д.
DG>>>>поддержки нескольких точек зрения — нет, ЗХ>>>Мммм... Мне кажется, для энциклопедии правильный подход — именно используемый в Википедии NPOV (Neutral Point Of View) DG>>В идеале — да. DG>>но на горячие (на flame-овые) темы — обычно NPOV не бывает.
A>горячие головы можно остудить баном или запретом редактирования статьи...
дык проблема не в самом flame-е, а в том, что NPOV на данный момент просто нет, т.к. проверить, чья точка зрения правильнее — можно будет проверить когда-то потом.
ps
вот, что, например, писать про астрологию?
что это лженаука, или что это наука?
а ведь что не напиши, другие обидяться.
DG>>>>>Структуризации — нет, ЗХ>>>>Ну, вообще-то категории там есть. DG>>>категории — это лишь один из инструментов структуризации
A>>а какие нужны еще?...
DG>Отношение частное — общее, DG>отношение целое — части, DG>порядковые отношения, DG>и т.д.
Проблема сложной структуризации — в том, что она очень тяжело поддерживается силами самих пользователей.
DG>дык проблема не в самом flame-е, а в том, что NPOV на данный момент просто нет, т.к. проверить, чья точка зрения правильнее — можно будет проверить когда-то потом.
DG>ps DG>вот, что, например, писать про астрологию? DG>что это лженаука, или что это наука? DG>а ведь что не напиши, другие обидяться.
Здравствуйте, nzeemin, Вы писали:
N>Посмотри вот это: N>http://ru.livecode.org/index.php/Заглавная_Страница N>- человеком двигали вполне благие намерения. И движок там от Википедии (Медиавики). А получилось черти что. А все почему? Потому что (i) не надо распыляться и пытаться охватить все на свете и (ii) очень важна грамотная классификация/категоризация.
Хм... а что именно там "черти что"? На первый беглый взгляд достаточно интересный проектик и почти то, что Зверек описывал.
Здравствуйте, Зверёк Харьковский, Вы писали:
AVK>>Все то же можно сделать и в случае VCS, вопрос в инструменте.
ЗХ>Тогда это будет wiki, реализованная поверх VCS
Неа. VCS намного круче чем wiki. Это вики такая куцая м примитивная VCS.
AVK>>Браузер в любом случае очень плохо подходит для редактирования кода (его как минимум один раз нужно скомпилировать и запустить).
ЗХ>Если внимательно почитать исходное сообщение, там это учтено.
страница типа "страницы ссылающиеся на эту страницу"... не совсем то, но...
DG>отношение целое — части,
ссылки внутри статьи на более подробное описание некоторых терминов... все таки гипертекст...
DG>порядковые отношения, DG>и т.д.
DG>дык проблема не в самом flame-е, а в том, что NPOV на данный момент просто нет, т.к. проверить, чья точка зрения правильнее — можно будет проверить когда-то потом. DG>ps DG>вот, что, например, писать про астрологию? DG>что это лженаука, или что это наука? DG>а ведь что не напиши, другие обидяться.
с этим примером все просто, здесь используется точка зрения официальной науки...
Более того, отмазка "ищите в поиске на rsdn" оказывается неконструктивной. Я пользуюсь каждый день как минимум десятком сайтов. Стоит ли мне запоминать, в каком месте на каждом сайте расположен запрос поиска, и потом мучиться с его убогой, или просто особенной сортировкой в результатах выдачи? (Честно говоря, именно из-за плохого поиска и появляются сообщения, которые уже на 20 раз обсуждались — человеку проще задать вопрос, чем найти его)
Возможно, нагрузку можно каким-то образом перенести на клиента (скачивается программа, в которую уже встроен редактор; каким-то образом полагаться на установленный у клиента компилятор, и т.п.). JetBrains, ау?!
