Здравствуйте, Кирилл Осенков, Вы писали: КО>как вы ее организуете?
Одного китайца спросили как ему удалось так хорошо выучить русский язык. Он ответил:
в день я учу 10 рисский слов в десять дней тысяча и все они здесь (показывает пальцем на голову) в зопе!
Здравствуйте, Кирилл Осенков, Вы писали:
L>>Ты это серьезно? КО>Мужики, только не говорите мне, что у вас в IE (Opere, Netscape и т.д.) папка Favorites пустая, сорцы сданных проекты бесследно удаляются с винта в день сдачи, каждый раз при необходимости написать каркас MDI приложения вы его пишете заново с нуля, каждый раз, когда вам нужно зайти на сайт по ООП вы лезете в Гугл, слыхом не слыхивали, что такое репозиторий, и пишете иерархии классов с твердой уверенностью, что после сдачи проекта их можно будет смело убить???
IMHO лучшая аккумуляция опыта — это завершающие конспектирование материала. Такие конспекты со временем могут превратиться в полноценную книжку которую можно даже издать. Но для меня например тратить время на такой конспект — просто жалко. Лучше не изобретать велосипед а купить готовую энциклопедию по данной тематике.
Тем не менее я собираю все: программы, инструменты разработки, результаты своего труда, книги и материалы, и даже некоторые письма, я не говорю уже о музыке и видео. Критерий отбора всегда интуитивен, в основном это — полезность. Свой многочисленный архив я периодически перебираю, что-то выбрасываю, что-то обновляю. Вообщем, это тоже самое что обустраивать собственную комнату
Некоторое время я был как и ты заморочен на каталогизации материала. Нашел The Brain и мне очень понравилось. Но потом бросил — потому что усилия на поддержания огромной библиотеки — огромны, и для меня выход — либо помнить все самому и хранить все в максимально упрощенной структуре, либо нанять специальную девочку — чтобы вела мою личную библиотеку. Но поскольку хорошей девочки-библиотекаря я пока не нашел, пришлодиться помнить все самому, а с каталогизацией — завязать.
Библиотекарское это дело — каталогизировать и хранить информацию для будующего реюза. А я — инженер-разработчик программ.
Я для себя создал структуру подкаталогов (которая иногда менялась) и пользуюсь. Структурируется все разбиением по категориям, причем все нацеленно прежде всего на удобную работу и поиск файлов и каталогов для текущих проектов и часто-используемых-вещей:
(ниже приведены смысловые аналоги каталогов, у меня они все на английском и названы в нужном порядке по алфавиту для удобства просмотра в сортированном виде)
Графика
Звукозапись
Композиторство
Разработка
Дизайн(R&D)
Движки/технологии
Игры
Веб
Аутсорсинг
Утилиты
Мысли
Доки
Демки
Статьи
Писанина
Избранное-любимое (фильмы,книги)
Игры
Лучшие
Классные
Эмуляторы
Freeware/Shareware
Хорошие
MMORPG
MUD
PBeM
Римейки
Ретро(коллекция)
+Доки
+Редакторы
+Карты
+Сохраненки
+Утилиты
Игры-временные
Почта
Архив(по годам)
Сеть
Программы
Расшаренное
Хранилище
Программы(инсталляторы)
Код
Библиотеки (SDL,GDIPlus,boost,FMOD,ogg,stlport,etc.)
SDK
Исходники(игр,движков)
Доки
Книги
Картинки
Фотографии
Музыка(mp3,mod,midi,sid,etc.)
Звуки
Демки(демосцена)
"Флэшки"
Видео
Работа
Пока-не-сортированное(периодически раскидывается)
КО>Мужики, только не говорите мне, что у вас в IE (Opere, Netscape и т.д.) папка Favorites пустая
Меньше десяти ссылок. Посмотрел, прочитал — сохрани текст или убей ссылку.
КО> Свалил все ссылки в кучу, а теперь понадобилось — а разобраться, что где лежит, сложно.
Сваливать нужно в кучки ПО ТЕМАМ. А на аннотации НУЖНО забивать. Они уменьшают производительность.
КО>Или понадобился мне например, Color Picker, который я когда-то писал, я его выдрал из старого проекта, а через две недели пришлось модифицировать старый — вопрос, мне что, обе версии модифицировать? Нутром чую, что информация должна существовать в единственном экземпляре, а как умные люди этого добиваются, не знаю.
Если по задаче нужно модифицировать оба — модифицируй оба. Можно выделить общий контрол в отдельный проект и на него из других ссылаться — тоже очень правильный способ.
КО>Так что, народ? Вы хотите сказать, "чувак, не ети себе мозги"? КО>Или как?
Именно так. И советую над этим серьёзно задуматься. Производительность труда не должна падать от бестолковых самокопаний.
[зверьковыгрызено]
Поддерживаю.
Господа хорошие, поиск — это конечно гут.
Однако ж я вот допустим осваивал новый язык Перл (это к примеру). 2 дня поиска по инету дало мне около 5 полезных эл. учебников и штук 30 статеек — некоторые полезные. некоторые не очень. В данный момент все эти поиски объяснялись только интересом, но, допустим, через 2 месяца (года, десятилетия) я вдруг захочу писать на Перле. И что? Опять 2,3 дня, неделю искать инфу? или зайти в папочку Перл на диске?
Помимо тог Буч, Кнут, Страуструп, Рихтер, Вандевуд... кто-то откажется от книжек с anatolix.naumen.ru?
А таких книг не так уж и мало, чтобы все сложить в одну папочку и юзать.
Кроме того... если я уже с этой задачей справился, найдя доки, то почему, встретившись с ней через 3 года, я должен опять перелопатить пол-инета (где, может быть. и сат-то уже закрылся), а не запустить поиск по своей базе, в которой это ТОЧНО ЕСТЬ и будет найдено (причем не среди 10^10 ссылок с теми же ключевыми словами, а именно то. что я хочу?)
По-моему, это какое-то излишне легковесное отношение к опыту — нашел раз, найду и еще раз.
(Все то же самое, и в существенно больщей степени, касается кода)
Здравствуйте, Vasili Trifonov, Вы писали:
VT>Просто Библиотеки сохраняют ключевую информацию в нашей цивилизации. И мне просто нет смысла дублировать их работу.
дык... если я — разработчик ПО, то мои основные инструметы — это знания.
тут по ананлогии с мастерской — можно, кончено, каждый раз у одних знакомых одолжить пилу, у других — молоток, у соседа — дрель.
но если тебе приходится работать в мастерской часто, ты не поленишься оборудовать ее так, чтобы все было удобное и под рукой.
вот.
Вот вчера наткнулся. http://www.pindersoft.com/sourcecode.htm Правда, мне не понравилось. Если бы было бы такое же, но еще чтобы файлы можно было бы к записям цеплять...
Вообще программист наверное должен с приобретением опыта вести такой своего рода дневник, такую личную библиотеку, в которой он накапливает мысли, идеи, решения, алгоритмы, подходы, куски кода, тьюториалы, библиотеки, ссылки, советы, методики и т.д. и т.п.
Внимание вопрос. Поделитесь пожалуйста опытом, если кто такую библиотечку ведет:
как вы ее организуете,
структурируете,
по каким принципам упорядочиваете информацию
и в каком формате ее храните, как выбираете форматы,
как добиваетесь единообразия оформления,
комментирования
и консервации информации (я имею ввиду: нет же смысла писать, какие пункты меню нужно нажимать, потому что с выходом новой версии это все равно устареет — как выделить нестареющую квинтэссенцию из полученного опыта?)
Приветствуется любая информация по этому поводу. Спасибо.
ИМХО аккумуляция опыта — это вообще бесполезное занятие.
Вот к примеру Архимед в ванной вдруг прозрел закричал эврика и сформулировал закон Архимеда . Если рассмотреть подробно этот процесс то можно сказать что есть две фазы:
1) откровение или прозрение — когда все стало ясно
2) формализация — когда абстрактное прозрение оборачивается в слова дела и т.д.
Совершенно очевидно, что первое самое главное, а формализация второстепенное. Если и имеет смысл что-то аккумулировать так это откровения и прозрения. А как их зааккумулируешь?
Хранить в памяти можно только то что уже формализовано, а в прозрениях можно только пребывать. Т.е. мудрый муж когда к нему приходит прозрение должен отворачиватся от падения в формализацию и должен стремится удержать и углубить состояние прозрения.
Т.е. бесполезно собирать кучу текстов в папочки или набивать память разными методиками. Лучше развивать концентрацию и сосредоточенность.
Здравствуйте, Кирилл Осенков, Вы писали:
КО>Здравствуйте, EyeGem, Вы писали:
EG>>(ниже приведены смысловые аналоги каталогов, у меня они все на английском и названы в нужном порядке по алфавиту для удобства просмотра в сортированном виде) КО>А как это?
Так, чтобы названия были краткими, максимально простыми и шли в субъективно-удобно-используемом порядке. В примере ниже заметь вляиние этих факторов на порядок и группировку каталогов.
Пример:
Games\
Best - здесь любимые и самые лучшие игры (первые в списке!)
Cool - здесь понравившиеся, но не дотягивающие до Best (вторые в списке!)
Emul - эмуляторные (ATARI,C64,GAMEBOY,NES,NIN64,PSX,SEGA,SNES,ZXSPECT)
Free - shareware/freeware, причем как инсталльники-архивы, так и установленные
Good - просто неплохие игры (включая разархивированные из Retro и др.)
MMORPG - }
MUD - } здесь собраны все интернет-игры
PBeM - }
Remake - архивы с римейками ретро-игр
Retro - архивы с ретро-играми
ZDocs - доп.инфо
ZEdit - редакторы
ZMaps - доп.карты и свои карты
ZSave - сохраненки от недопройденных игр и пр.
Здравствуйте, Кирилл Осенков, Вы писали:
КО>Или понадобился мне например, Color Picker, который я когда-то писал, я его выдрал из старого проекта, а через две недели пришлось модифицировать старый — вопрос, мне что, обе версии модифицировать? Нутром чую, что информация должна существовать в единственном экземпляре, а как умные люди этого добиваются, не знаю.
Я бы вынес его в отдельную dll'ку, а в новом проекте либо отнаследовался либо сделал бы над ним обертку-адаптер.
Здравствуйте, Кирилл Осенков, Вы писали:
КО>Приветствуется любая информация по этому поводу. Спасибо.
Это если серьёзно на это всё посмотреть?
лучшее — осматривать как крупные Web-порталы, такие как этот , так и домашние страницы конкретных разработчиков, а так же то что "народ рекомендует и дяди дают" , а по исходникам, например такой как — www.torry.net (где создатели уж давно над какой-то новой системой хранения работают — аж с апреля — уже не дождемся наверно...)
На щас: многое храню у себя локально на винте. Расладываю по папкам файловой системы ...
Мнение личное — идти от основы — хранить исходники... потом уж — хэлпы на них, ответы на форумах, статьи, публикации храним там же... всё хорошо укладывается в рамки одиночного наследования классов... кажный базовый наследуемый класс — подпапка с файлом его исходника... для сборок — начинай название папки по фирме-разработику или по автору, а для исходников, содержащих только методы (разные там API) — можно хранить по категориям (напр.: Math, работа со string, GUI, 3D, IDE-experts и проч.) и в них их help-ы и demo-сы... и не забывай указывать дату создания версии, а то по "version" можно запутаться....
Вооще , если это вопрос из очень и очень далёкого будующего... требуется много и очень много энтузиазма ....
Далее пойдёт моя "Маниловщина" про далёкое-далёкое будующее :
когда-нибудь исходники и сопутствующяя их "поддержка" будут храниться в РЕПОЗИТОРИИ, основанном на языковых структурах (имеративного программирования ), поддерживая все прелести асинхронности разработки и дальнейшего доступа "как во времени так и в пространстве" (щас же нам пока дан лишь CVS )
меня греет надежда!!! — введение в языковые конструкции изменяемых классов — похожая задумка имеется — helper-class в прогнозах о Native Delphi (http://www.optim.ru/cs/2002/3/delp/delp.asp) Эта ннадежда очень мааленькая, но принципиальная (и опирается на порядком "подмятую под M$" Borl& )
я верю!!! в создание РЕПОЗИТОРИЯ ИСХОДНИКОВ как распределенной базы и самые лучшие механимы к ней в придачу: транзакции с многоверсионностью как в InterBase и удобное хранение (для этого может быть подойдёт XML или чего получше — )
и насладился б!!! если к нему сделали УНИВЕРСАЛЬНУЮ СРЕДУ РАЗРАБОТКИ (встроенную в ОС). Очень хочется, что бы все программы могли работать из под среды разработки — т.е. все прелести DesignTime, компиляции "по чястям", сильного отладчика и профиллера — полный контроль над используемым инструментом...
как "эту прелесть" практически реализовать и не обидеть разработчиков коммерческого софта —
дальше уже мелизмы: форумы поддержки и большое количество "аскетичных" грамотных утилит в поддержку "этакой затеи"...
КО>Внимание вопрос. Поделитесь пожалуйста опытом, если кто такую библиотечку ведет:
Память так устроена, что она сама всё нужное сохраняет. Любые инородные мнемотехники должны искореняться с гестаповской жестокостью.
К примеру, я постоянно слежу за статьями по дотнету. Распечатываю, читаю и выбрасываю большей частью. И это правильно! Бывает, сохраняю — когда есть много важных технических деталей, не относящихся к пониманию, но всё равно необходимых.
Для сохранения просто создал дерево каталогов и бросаю в него соответственно теме. Исходники, статьи — всё в одном дереве по темам. Уже накопилось порядком.
В случае чего — поиском всё находится за несколько секунд.
А писать рефераты и квинтессенции — неблагодарное и ненужное дело.
Здравствуйте, Vasili Trifonov, Вы писали:
VT>У меня скажем бесценный в свое время ксерокс книжки Чарльза Петзольда про Programming Windows 3.1 сейчас уже второй месяц обслуживает туалет у кошки. Такова жизнь
Мне сдается, нужно различать устаревающие знания и неустаревающие знания. Вот, например, вопрос на засыпку: какая разница между "Алгоритмами" Кормена и К. и "Программирование на VC++ 5 под MFC" Кейт Кактамеезовут? Или между ссылкой на статью по ООП на домашней странице Васи Пупкина и ссылкой на ooad.asf.ru? Или код, вычисляющий день недели на Turbo Basic 3.0 vs. тот же код как отдельный класс C++?
Нестареющую информацию (абстрагированную от контекста, в котором она родилась) выбрасывать, ИМХО, просто расточительно. Сохраняя полезную информацию, мы инвестируем в удобство разработки будущих проектов. Я убежден, что временные затраты на создание такой библиотеки и ее (осмысленную!) поддержку в будущем должны начать окупаться уже где-то через несколько месяцев (спорное утверждение, но все же).
ЗХ>>Здравствуйте, Vasili Trifonov, Вы писали:
VT>Но при этом: Что толку от знаний которыми ты не пользуешься [никогда не будешь пользоваться]? (C) Дон Хуан. Я именно это и имел ввиду.
Да, кстати, вот еще что: никто не заставляет сохранять все подряд — это действительно просто глупо. Просто если к тебе попалась ссылка, или интересный кусок кода, или книга в pdf формате — нужно секунд 20-30 уделить на то, чтобы подумать: может ли это понадобиться мне или моим знакомым в будущем? Если есть такая возможность, положить ее в архив (за логарифмическое время!)
/*поскипано*/
K>>Т.е. бесполезно собирать кучу текстов в папочки или набивать память разными методиками. Лучше развивать концентрацию и сосредоточенность. КО>Хм. Самоулучшение, ниндзя, поза лотоса — это конечно рулез. Но информация-то берется извне, и потоки ее невероятны, линейно упорядочивать информацию ужасно неэффективно, нужна структура: например, дерево или хотя бы какой-нибудь индекс. Я об этом и говорил: информации приходит много, как ее сохранить и удержать в порядке?
Информация берется изнутри в откровениях и прозрениях, то что поступает из вне это уже побочный продукт, результат формализации. Причем в этом внешнем потоке информации вреда гораздо больше чем пользы, если весь ум заполнен из вне то нет места чтобы заполнится изнутри. В том-то и вся проблемма, кажется что в школах и институтах нас чему-то учат, но на самом деле в результате такого обучения человек крепко привязывается к колесу заблуждений. На познание такое обучение не направлено. Скорее наоборот
КО>Как может помочь концентрация, когда мне нужно сделать обзор новых достижений динамической геометрии на сегодняшний момент? Или мне понадобилась теорема из матана, которую мы четыре года назад доказывали? (а она действительно понадобилась, даю слово!) Мне ее как, самому заново выводить?
Здась надо мыслить более глобально, пример с Архимедом показывает, что наука больше склонна к формализациям и рассуждениям неджели к откровениям или прозрениям. Т.е. любой здравомыслящий человек стремящийся к познанию обнаружит, что из многих способов познания наука это наверное один из самых худших. К чему тогда доказывать теоремы и идти самым неэфективным путем?
Здравствуйте, Кирилл Осенков, Вы писали:
КО>Вообще программист наверное должен с приобретением опыта вести такой своего рода дневник, такую личную библиотеку, в которой он накапливает мысли, идеи, решения, алгоритмы, подходы, куски кода, тьюториалы, библиотеки, ссылки, советы, методики и т.д. и т.п.
КО>Внимание вопрос. Поделитесь пожалуйста опытом, если кто такую библиотечку ведет:
КО>
КО>как вы ее организуете,
КО>структурируете,
КО>по каким принципам упорядочиваете информацию
КО>и в каком формате ее храните, как выбираете форматы,
КО>как добиваетесь единообразия оформления,
КО>комментирования
КО>и консервации информации (я имею ввиду: нет же смысла писать, какие пункты меню нужно нажимать, потому что с выходом новой версии это все равно устареет — как выделить нестареющую квинтэссенцию из полученного опыта?) КО>
КО>Приветствуется любая информация по этому поводу. Спасибо.
через несколко лет будешь писать на другом языке, под другой ОС да и теми же средствами реализуешь одинаковую функциональность иначе (лучше)
Никак. Делать то, что ты описал,
наверное иногда полезно, но в целом мне лично скучно...
Опять же, зачем?
С другой стороны, если у кого-то опыта много и он хочет им поделиться с другими,
то он садится и пишет книжку.
Вот это проверенный способ аккумуляции и передачи опыта.
Есть и другие способы. FAQ, HOWTO и прочее — из этой же оперы.
L>Ты это серьезно?
Мужики, только не говорите мне, что у вас в IE (Opere, Netscape и т.д.) папка Favorites пустая, сорцы сданных проекты бесследно удаляются с винта в день сдачи, каждый раз при необходимости написать каркас MDI приложения вы его пишете заново с нуля, каждый раз, когда вам нужно зайти на сайт по ООП вы лезете в Гугл, слыхом не слыхивали, что такое репозиторий, и пишете иерархии классов с твердой уверенностью, что после сдачи проекта их можно будет смело убить???
Возможно я слишком педантично все это расписал в первом постинге — но какие-то элементы должны же быть? Я уже просто дозрел до того, что свои ссылки и сорцы нужно как-то тематически упорядочивать, а как это сделать разумно, я не знаю. Вот например, я когда-то долго разбирался в инете, как писать резюме, рекомендательные письма и т.д. Свалил все ссылки в кучу, а теперь понадобилось — а разобраться, что где лежит, сложно. Или понадобился мне например, Color Picker, который я когда-то писал, я его выдрал из старого проекта, а через две недели пришлось модифицировать старый — вопрос, мне что, обе версии модифицировать? Нутром чую, что информация должна существовать в единственном экземпляре, а как умные люди этого добиваются, не знаю.
Так что, народ? Вы хотите сказать, "чувак, не ети себе мозги"?
Или как?
Здравствуйте, bkat, Вы писали:
B>Никак. Делать то, что ты описал, B>наверное иногда полезно, но в целом мне лично скучно... B>Опять же, зачем?
Ну, например, я лет пять назад разбирался с конечными автоматами и регулярными выражениями. Нашел в сети литературу, сайты, примеры. Наработал что-то свое. Как мне это все законсервировать на будущее? Сейчас вот опять понадобилось — так что, опять разбираться по новой?
B>С другой стороны, если у кого-то опыта много и он хочет им поделиться с другими, B>то он садится и пишет книжку. B>Вот это проверенный способ аккумуляции и передачи опыта. B>Есть и другие способы. FAQ, HOWTO и прочее — из этой же оперы.
Это все да, но еще лучше — RSDN Можно просто свои ссылки опубликовать на RSDN, и делов. Проблема: если каждый начнет публиковать ссылки, которые он считает нужными, начнутся проблемы — станет тяжело быстро найти нужную ссылку. Хотя, хрен его знает...
Здравствуйте, Кирилл Осенков, Вы писали:
КО>Здравствуйте, bkat, Вы писали:
B>>Никак. Делать то, что ты описал, B>>наверное иногда полезно, но в целом мне лично скучно... B>>Опять же, зачем? КО>Ну, например, я лет пять назад разбирался с конечными автоматами и регулярными выражениями. Нашел в сети литературу, сайты, примеры. Наработал что-то свое. Как мне это все законсервировать на будущее? Сейчас вот опять понадобилось — так что, опять разбираться по новой?
Скорей все да.
Только второй раз все пройдет быстрее, потому как опыт...
Здравствуйте, Кирилл Осенков, Вы писали:
КО>Вообще программист наверное должен с приобретением опыта вести такой своего рода дневник, такую личную библиотеку, в которой он накапливает мысли, идеи, решения, алгоритмы, подходы, куски кода, тьюториалы, библиотеки, ссылки, советы, методики и т.д. и т.п.
КО>Внимание вопрос. Поделитесь пожалуйста опытом, если кто такую библиотечку ведет:
КО>
КО>как вы ее организуете,
КО>структурируете,
КО>по каким принципам упорядочиваете информацию
КО>и в каком формате ее храните, как выбираете форматы,
КО>как добиваетесь единообразия оформления,
КО>комментирования
КО>и консервации информации (я имею ввиду: нет же смысла писать, какие пункты меню нужно нажимать, потому что с выходом новой версии это все равно устареет — как выделить нестареющую квинтэссенцию из полученного опыта?) КО>
КО>Приветствуется любая информация по этому поводу. Спасибо.
Помоему это и не нужно делать , я к такому выводу пришел недавно, не нужно "хлам с улицы домой тащить".
Нашел инфу в инете — никуда она от тебя не денется. Не надо ее сохранять. Нужно будет — наберешь yandex.ru введешь
мне нада xxxx и будут тебе ссылки. Почитаешь когда нада будет.
Здравствуйте, Колобок, Вы писали:
К>Помоему это и не нужно делать , я к такому выводу пришел недавно, не нужно "хлам с улицы домой тащить". К>Нашел инфу в инете — никуда она от тебя не денется. Не надо ее сохранять. Нужно будет — наберешь yandex.ru введешь К>мне нада xxxx и будут тебе ссылки. Почитаешь когда нада будет.
Здравствуйте, Vasili Trifonov, Вы писали:
VT>Здравствуйте, Кирилл Осенков, Вы писали:
L>>>Ты это серьезно? КО>>Мужики, только не говорите мне, что у вас в IE (Opere, Netscape и т.д.) папка Favorites пустая, сорцы сданных проекты бесследно удаляются с винта в день сдачи, каждый раз при необходимости написать каркас MDI приложения вы его пишете заново с нуля, каждый раз, когда вам нужно зайти на сайт по ООП вы лезете в Гугл, слыхом не слыхивали, что такое репозиторий, и пишете иерархии классов с твердой уверенностью, что после сдачи проекта их можно будет смело убить???
VT>IMHO лучшая аккумуляция опыта — это завершающие конспектирование материала.
Кстати, на некоторых проектах так и делают.
Т.е. специально собираются и обсуждают, что было хорошо, что — было плохо.
Какие проблемы были и как их можно избежать потом.
Все это документируется и является частью проектной документации.
Может быть очень полезным, если подходить к этому неформально.
B>Кстати, на некоторых проектах так и делают. B>Т.е. специально собираются и обсуждают, что было хорошо, что — было плохо. B>Какие проблемы были и как их можно избежать потом. B>Все это документируется и является частью проектной документации. B>Может быть очень полезным, если подходить к этому неформально.
Эта практика получила даже собственное название — Project Review. Я ее делаю постоянно
КО>Ну, например, я лет пять назад разбирался с конечными автоматами и регулярными выражениями. Нашел в сети литературу, сайты, примеры. Наработал что-то свое. Как мне это все законсервировать на будущее? Сейчас вот опять понадобилось — так что, опять разбираться по новой?
Или статью напиши, или просто скинь всё в папку и спи спокойно.
Я, собственно, первоначально имел ввиду примерно это, когда вопрос задавал, только не смог правильно описать Сейчас, пойду поглядеть, что там народ обсуждает (мой земляк Зверёк, похоже, борется с теми же проблемами )
КО>Я, собственно, первоначально имел ввиду примерно это, когда вопрос задавал, только не смог правильно описать Сейчас, пойду поглядеть, что там народ обсуждает (мой земляк Зверёк, похоже, борется с теми же проблемами )
Вишь поиск какая классная штука, ничего не аккумулировал а информацию достал.
Эх, cкоро на свободу. Сидеть осталось 28 дней. Я в бане, а чего больше никто не моется ?
КВБ>Вишь поиск какая классная штука, ничего не аккумулировал а информацию достал.
p.s. он в инете сам по себе аккумулируется. Как что хорошее появляется оно тут же расползается по куче сайтов.
Остается только научиться пользоваться поисковыми системами.
Эх, cкоро на свободу. Сидеть осталось 28 дней. Я в бане, а чего больше никто не моется ?
Я например использую следующие вещи:
1. Структуру фолдеров практически со всеми проектами с которыми работал (правда это монстр примерно 80-ть тысяч файлов размером 6Gb). Имя проекта или название платформы для маленьких проектов. Внутри разделение на под-проекты и т.п.
2. Exchange: структура фолдеров: первый уровень некие глобальный категории (my project, personal, internal, temp, smile, ...) второй уровень название проекта, ну и внутри проекта необхоодимая классификация.
3. Exchange: записи с назначенными категориями (очень удобно искать).
4. Фавориты в IE: первый уровень глобальные категории (development, personal, information, art, libs, smile,...)
5. StarTeam: на каждый проект создается свой проект в StarTeam-е, проект мапится на фолдер в 1-ом пункте, а также содержит баги и т.п.
Основные проблемы:
а) находится все это в разных местах
б) искать по структуре фолдеров трудно
Что касательно общего кода, то я стараюсь держать оригинал в одном месте, а в тех проектах где необходимо использовать их делаю копии. Но стараюсь редактировать только оригинал, либо потом синхронизировать.
Здравствуйте, Vasili Trifonov, Вы писали:
VT>Библиотекарское это дело — каталогизировать и хранить информацию для будующего реюза. А я — инженер-разработчик программ.
Дизайнерское это дело — юзабильный интерфейс делать
Техврайтерское это дело — код комментировать и документировать
Менеджерское это дело — за сроками следить
Тестерское это дело — баги ловить
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>Здравствуйте, Vasili Trifonov, Вы писали:
VT>>Библиотекарское это дело — каталогизировать и хранить информацию для будующего реюза. А я — инженер-разработчик программ. ЗХ>Дизайнерское это дело — юзабильный интерфейс делать ЗХ>Техврайтерское это дело — код комментировать и документировать ЗХ>Менеджерское это дело — за сроками следить ЗХ>Тестерское это дело — баги ловить
ЗХ>так, что ль?
И да и нет. Но в идеале — ты прав.
Просто Библиотеки сохраняют ключевую информацию в нашей цивилизации. И мне просто нет смысла дублировать их работу.
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>Здравствуйте, Vasili Trifonov, Вы писали:
VT>>Просто Библиотеки сохраняют ключевую информацию в нашей цивилизации. И мне просто нет смысла дублировать их работу.
ЗХ>дык... если я — разработчик ПО, то мои основные инструметы — это знания.
Конечно.
Но при этом: Что толку от знаний которыми ты не пользуешься [никогда не будешь пользоваться]? (C) Дон Хуан. Я именно это и имел ввиду.
У меня скажем бесценный в свое время ксерокс книжки Чарльза Петзольда про Programming Windows 3.1 сейчас уже второй месяц обслуживает туалет у кошки. Такова жизнь
Здравствуйте, Vasili Trifonov, Вы писали:
VT>Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>>Здравствуйте, Vasili Trifonov, Вы писали:
VT>>>Просто Библиотеки сохраняют ключевую информацию в нашей цивилизации. И мне просто нет смысла дублировать их работу.
ЗХ>>дык... если я — разработчик ПО, то мои основные инструметы — это знания.
VT>Конечно. VT>Но при этом: Что толку от знаний которыми ты не пользуешься [никогда не будешь пользоваться]? (C) Дон Хуан. Я именно это и имел ввиду.
никто ж не спорит. но ты ведь не отрицаешь, что кучу енужных и полезных знаний надо все-тки как-то стуктурировать?
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>никто ж не спорит. но ты ведь не отрицаешь, что кучу енужных и полезных знаний надо все-тки как-то стуктурировать?
Нет конечно. Но тут спасает простое структурирование по иерархии директорий. Причем иерархия выбирается максимально простой.
Но все равно получается достаточно сложной, у меня только библиотека книг содержит порядка сотни папок по разным тематикам а есть ведь еще инсталляции, примерчики, итд.
Кстати на эту тему уже здесь хорошо высказались.
И кстати, если вы (на пару с Кириллом) напишите какой-нибудь удобный каталогизатор, я буду рад им воспользоваться и предложить кучу полезных идей с точки зрения его пользования. А опыта уж хватит — с 92-го по 97-год у меня была своя BBS а после — просто как личная библиотека...
Только помните, что это задача еще серьезнее чем google, как мне кажется
Я бы и сам поучаствовал бы, но увы пока и так много работы
Здравствуйте, Vasili Trifonov, Вы писали:
VT>И кстати, если вы (на пару с Кириллом) напишите какой-нибудь удобный каталогизатор, я буду рад им воспользоваться и предложить кучу полезных идей с точки зрения его пользования. А опыта уж хватит — с 92-го по 97-год у меня была своя BBS а после — просто как личная библиотека...
идеи завсега welcome — и чем раньше, тем лучше (меньше переделывать будет )
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>Здравствуйте, Vasili Trifonov, Вы писали:
VT>>И кстати, если вы (на пару с Кириллом) напишите какой-нибудь удобный каталогизатор, я буду рад им воспользоваться и предложить кучу полезных идей с точки зрения его пользования. А опыта уж хватит — с 92-го по 97-год у меня была своя BBS а после — просто как личная библиотека...
ЗХ>идеи завсега welcome — и чем раньше, тем лучше (меньше переделывать будет )
Тогда программа-максимум (в порядке как это пришло мне в голову):
0. За основу функциональности можно взять MSDN (Содержание, Индекс, Поиск, Favorites)
1. Чтобы все хранилось в простой структуре директориев и могло поддерживаться и без умного каталогизатора;
2. Бывает так что часть каталога (E:\Library) на одном диске, часть на другом (F:\Library) => нужно иметь виртуальный каталог (Library) (т.е. уметь склеивать каталоги);
3. Поддержка структуры должна быть максимально простой (т.е. все что можно импортировать на автомате, можно импортировать на автомате — cм. п.1);
4. Статистика расходуемого места по папкам;
5. Общий список файлов по всем директориям;
6. Ставить ключевые слова в соответствие файлу;
7. Поиск по ключевым словам
8. Поиск по содержанию файла
9. Линки между папками (Languages\C#\.NET и Platforms\.NET должны приводить к одной реальной папке)
10. Должна быть поддержка выяснения какие новые файлы появились в библиотеке (с тем чтобы если я имею две библиотеки — дома и на работе — я мог их синхронизировать)
Вроде пока все. Еще что придумаю. Скажу. Кстати, мой email в инфе есть, так что буду рад если ты меня будешь держать в курсе что происходит.
Кстати, не изобретаем ли мы велосипед, и WinFS не похожая ли хрень?
И я кой-чего добавлю:
VT>2. Бывает так что часть каталога (E:\Library) на одном диске, часть на другом (F:\Library) => нужно иметь виртуальный каталог (Library) (т.е. уметь склеивать каталоги);
Это да. Мне вот что интересно (Василий, вопрос риторический, поэтому если нет времени, не отвлекайся )
а оглавление хранить где-то отдельно и отображать на реальную структуру, или синхронизировать каждый раз? Ясно, синхронизировать долго. Но если отделить оглавление от собственно содержимого, то есть риск, что я положу что-нибудь в папку вручную, а оглавление этого не почувствует — потеряется синхронизация. Хотя, с чего это мне класть вручную, если у меня будет Зверьковый Библиотекарь
Т.е. я бы выделил два ключевых понятия — физические данные и абстрактное оглавление — интерфейс к ним.
VT>6. Ставить ключевые слова в соответствие файлу;
Да. Здесь можно думать о природе хранимых данных: а что собственно будет в библиотеке? Я сейчас предположу, а вы поправьте, если чего:
Ссылки URL — хранить наверное в .url файлах
Электронные книги — как есть (.pdf, .ps, .doc, .html, etc.)
Сорцы — как есть
Различного рода текстовые примечания — .doc
VT>9. Линки между папками (Languages\C#\.NET и Platforms\.NET должны приводить к одной реальной папке)
О! Супер! А я думал, как из древесной системы сделать граф!! Файл пусть лежит в одном месте, а ссылки на него можно развесить во многих местах.
Здесь лирическое отступление: мне не очень нравится, когда слишком много перекрестных ссылок — когда читаешь, такое чувство, что ты заблудился и тебе еще столько предстоит прочитать — плохо в графе ориентироваться, в дереве все же лучше — там есть порядок (линейный). Так что наверное, ссылки нужно размножать очень неохотно, иначе будет во-первых, тяжело за ними всеми следить, а во-вторых (ИМХО) можно заблудиться...
VT>10. Должна быть поддержка выяснения какие новые файлы появились в библиотеке (с тем чтобы если я имею две библиотеки — дома и на работе — я мог их синхронизировать)
Точно.
Теперь еще пару мыслей об оглавлении (т.е. интерфейсе ко всему этому хранилищу). Это множество элементов различного типа (ссылка, документ, сорец (ед. число от "сорцы") или еще что-нибудь). Оно может быть по-разному представлено.
Самое главное представление — тематическое (дерево, а в нем развешаны элементы, причем тип не играет роли — все вперемешку — ссылки, книги и т.д.) Т.е. в ветке "Programming\Graphics\OpenGL" вперемешку ссылки на сеть, пару книг, сорцы — все упорядочено по подтемам (общее, шейдеры, преобразования координат и пр.) Если сложно причислить элемент к теме — бросить в общее и не ломать себе мозги
Помимо этого дела, элементы должны обладать парой полей: собственно, тип элемента (что это? ссылка или книга?), ключевые слова ((C) Vasili Trifonov ), краткое описание, и что-то еще. Кстати, при ссылках можно хранить набор ключевых слов, при помощи которых эта ссылка была найдена в гугле — на случай, если сайт "переедет").
Да и вот еще что. Было бы здорово на основе оглавления уметь генерировать xml (или просто html) файлы со ссылками — чтобы можно было в сеть вешать, например, на свою домашнюю страничку (в идеале это даже ASP — ну короче, чтоб можно было сервер попросить прислать набор ссылок по OpenGL). При генерации можно было бы выбрать таблицу стилей (например, украденную с РСДН — очень уж она мне нравится )
А то я сейчас решил повесить на своей страничке красиво отсортированное содержимое своей папки "Favorites" — это 512 элементов — в Dreamweavere их склеивать из меню Favorites — НЕ ПРИКОЛЬНО...
Здравствуйте, Vasili Trifonov, Вы писали:
ЗХ>>идеи завсегда welcome — и чем раньше, тем лучше (меньше переделывать будет ) VT>Тогда программа-максимум (в порядке как это пришло мне в голову):
disclaimer: сразу предупреждаю, что я решил не создавать на винте какой-то структуры папок. Это решение пришло из долгого опыта, если есть желание, могу объяснить его корни, но оно непоколебимо.
Все книги будут храниться где-то внутри, в сжатом виде. При желании можно будет экспортировать часть или всю библиотеку, в том числе и как правильную структуру папок, но физически работать с книгами на винте, которые "внутри" библиотеки — крайне не рекомендуется.
VT>0. За основу функциональности можно взять MSDN (Содержание, Индекс, Поиск, Favorites)
будет больше.
VT>1. Чтобы все хранилось в простой структуре директориев и могло поддерживаться и без умного каталогизатора;
см. выше.
VT>2. Бывает так что часть каталога (E:\Library) на одном диске, часть на другом (F:\Library) => нужно иметь виртуальный каталог (Library) (т.е. уметь склеивать каталоги);
возможно, неплохая идея (типа хранить части бибиотеки в разных местах). понял. учту.
VT>3. Поддержка структуры должна быть максимально простой (т.е. все что можно импортировать на автомате, можно импортировать на автомате — cм. п.1);
на это и ориентируюсь, в основном.
VT>4. Статистика расходуемого места по папкам; VT>5. Общий список файлов по всем директориям;
пока не вижу смысла в связи с см. выше
VT>6. Ставить ключевые слова в соответствие файлу; VT>7. Поиск по ключевым словам VT>8. Поиск по содержанию файла
уже учтено.
VT>9. Линки между папками (Languages\C#\.NET и Platforms\.NET должны приводить к одной реальной папке) разумно
VT>10. Должна быть поддержка выяснения какие новые файлы появились в библиотеке (с тем чтобы если я имею две библиотеки — дома и на работе — я мог их синхронизировать)
уже учтено
VT>Вроде пока все. Еще что придумаю. Скажу. Кстати, мой email в инфе есть, так что буду рад если ты меня будешь держать в курсе что происходит.
да я думаю основные события будут тут светиться пока.
VT>Кстати, не изобретаем ли мы велосипед, и WinFS не похожая ли хрень?
не знаю... но за WinFS мне точно денег не заработать
Здравствуйте, Кирилл Осенков, Вы писали:
КО>Привет!
КО>И я кой-чего добавлю:
VT>>2. Бывает так что часть каталога (E:\Library) на одном диске, часть на другом (F:\Library) => нужно иметь виртуальный каталог (Library) (т.е. уметь склеивать каталоги); КО>Это да. Мне вот что интересно (Василий, вопрос риторический, поэтому если нет времени, не отвлекайся )
КО>а оглавление хранить где-то отдельно и отображать на реальную структуру, или синхронизировать каждый раз? Ясно, синхронизировать долго. Но если отделить оглавление от собственно содержимого, то есть риск, что я положу что-нибудь в папку вручную, а оглавление этого не почувствует — потеряется синхронизация. Хотя, с чего это мне класть вручную, если у меня будет Зверьковый Библиотекарь
см. мой ответ Василию
КО>Т.е. я бы выделил два ключевых понятия — физические данные и абстрактное оглавление — интерфейс к ним.
так и будет.
VT>>6. Ставить ключевые слова в соответствие файлу; КО>Да. Здесь можно думать о природе хранимых данных: а что собственно будет в библиотеке? Я сейчас предположу, а вы поправьте, если чего: КО>
КО>Ссылки URL — хранить наверное в .url файлах
подумаем
КО>Электронные книги — как есть (.pdf, .ps, .doc, .html, etc.)
на это — основная ориентация
КО>Сорцы — как есть
вот тут сомнения гложут меня. для сорцов нужны немножко другие вещи, нежели для книг — возможность удобного просмотра (подсветка синтаксиса), контроль версий, возможно, какой-то анализ. к тому же я предпочитаю отделыть мух от котлет — книги отдельно, библиотеки кода отдельно. но на вкус и цвет... на данный момент я по этому поводу думаю организовать возможность поддержки плагинов (давно задумано) и сделать всю эту поддержку сорцов отдельным плагином.
КО>Различного рода текстовые примечания — .doc
ну насчет свободных заметок — не знаю . вскрытие покажет.
но уж точно не .doc — все-тки самый закрытый формат
КО>
VT>>9. Линки между папками (Languages\C#\.NET и Platforms\.NET должны приводить к одной реальной папке) КО>О! Супер! А я думал, как из древесной системы сделать граф!! Файл пусть лежит в одном месте, а ссылки на него можно развесить во многих местах. КО>Здесь лирическое отступление: мне не очень нравится, когда слишком много перекрестных ссылок — когда читаешь, такое чувство, что ты заблудился и тебе еще столько предстоит прочитать — плохо в графе ориентироваться, в дереве все же лучше — там есть порядок (линейный). Так что наверное, ссылки нужно размножать очень неохотно, иначе будет во-первых, тяжело за ними всеми следить, а во-вторых (ИМХО) можно заблудиться...
пошмотрим
КО>Теперь еще пару мыслей об оглавлении (т.е. интерфейсе ко всему этому хранилищу). Это множество элементов различного типа (ссылка, документ, сорец (ед. число от "сорцы") или еще что-нибудь). Оно может быть по-разному представлено. КО>Самое главное представление — тематическое (дерево, а в нем развешаны элементы, причем тип не играет роли — все вперемешку — ссылки, книги и т.д.) Т.е. в ветке "Programming\Graphics\OpenGL" вперемешку ссылки на сеть, пару книг, сорцы — все упорядочено по подтемам (общее, шейдеры, преобразования координат и пр.) Если сложно причислить элемент к теме — бросить в общее и не ломать себе мозги
уже, уже, уже.
КО>Помимо этого дела, элементы должны обладать парой полей: собственно, тип элемента (что это? ссылка или книга?), ключевые слова ((C) Vasili Trifonov ), краткое описание, и что-то еще. Кстати, при ссылках можно хранить набор ключевых слов, при помощи которых эта ссылка была найдена в гугле — на случай, если сайт "переедет").
уже
КО>Да и вот еще что. Было бы здорово на основе оглавления уметь генерировать xml (или просто html) файлы со ссылками — чтобы можно было в сеть вешать, например, на свою домашнюю страничку (в идеале это даже ASP — ну короче, чтоб можно было сервер попросить прислать набор ссылок по OpenGL). При генерации можно было бы выбрать таблицу стилей (например, украденную с РСДН — очень уж она мне нравится )
уже. в идеале и будет возможность генерить что-то вроде РСДН — слева деревце, справа вверху — книжки в текущей папке, справа внизу — описание книжки и БОООЛЬШАЯ кнопка Загрузить
ЗЫ: все "уже" значат "уже запроектировано" а не "уже написано"
Здравствуйте, Кирилл Осенков, Вы писали:
КО>Зверёк, а на чем ты собственно пишешь, если не секрет?
на данный момент создаю основную систему классов — на С++, естественно
Интерфейс думаю на Билдере — не хочется очень уж много возиться с МФСями унд ВТЛями — да и знаю я их похуже.
По большому счету, с Билдером в смысле скорости и удобства создания интерфесов никто не сравнится
ЗХ>на данный момент создаю основную систему классов — на С++, естественно ЗХ>Интерфейс думаю на Билдере — не хочется очень уж много возиться с МФСями унд ВТЛями — да и знаю я их похуже.
ОК. Хозяин барин. А почему не .NET? Не C#? (Мы с тобой флеймить не будем, как скажешь, так и будет — мне просто интересно, почему такой выбор).
Здравствуйте, Кирилл Осенков, Вы писали:
ЗХ>>на данный момент создаю основную систему классов — на С++, естественно ЗХ>>Интерфейс думаю на Билдере — не хочется очень уж много возиться с МФСями унд ВТЛями — да и знаю я их похуже. КО>ОК. Хозяин барин. А почему не .NET? Не C#? (Мы с тобой флеймить не будем, как скажешь, так и будет — мне просто интересно, почему такой выбор).
не, ну ты будешь смеяться. не знаю я его. и в глаза не видел!
(кстати, для небольшой шароварной програмки требовать с собой 25-метровый NET — некузяво)
ЗХ>не, ну ты будешь смеяться. не знаю я его. и в глаза не видел! ЗХ>(кстати, для небольшой шароварной програмки требовать с собой 25-метровый NET — некузяво)
да, шутки шутками, а правда твоя я бы вот на ДотНете писал, т.к. C++ не знаю
Здравствуйте, EyeGem, Вы писали:
EG>(ниже приведены смысловые аналоги каталогов, у меня они все на английском и названы в нужном порядке по алфавиту для удобства просмотра в сортированном виде)
А как это?
EG>Пока-не-сортированное(периодически раскидывается)
Н-даа, у меня сейчас в пока-не-отсортированном этак 900 ссылок Но это уже вопрос моей (полностью отсутствующей) самодисциплины
Здравствуйте, Kluev, Вы писали:
K>ИМХО аккумуляция опыта — это вообще бесполезное занятие.
Опыт — понятие очень широкое. Я, когда задавал вопрос, имел ввиду опыт работы за компом в самом широком смысле (если не уточнил, сорри). Я имел ввиду прежде всего сохранение однажды приобретенной информации, чтобы в будущем не тратить время и ресурсы на повторное ее добытие. Кеширование. К примеру, понадобились мне онлайн-словари — полез один раз, погуглил, выбрал несколько лучших — запхнул в свою копилку урлы (как именно хранить эту информацию — вопрос уже совершенно другой).
Если мой уважаемые собеседник сносит сданные проекты с винта, библиотеки пишет только для использования на этой неделе, и каждый раз при необходимости уйти на какой-нибудь сайт лезет в гугл, то позволю себе скромно выразить свою критику в адрес его стиля работы и уважения к своему времени Ладно, я шучу так, не обижайся, я думаю мы просто недопоняли друг друга
K>Совершенно очевидно, что первое самое главное, а формализация второстепенное. Если и имеет смысл что-то аккумулировать так это откровения и прозрения. А как их зааккумулируешь?
Что-то мы немного отклонились от темы — ну и ладно, пофилософствуем, раз уж так Мне сдается, прозрение — это верхушка айсберга, вишенка на торте, венец творения — это результат долгого и мучительного процесса. Сколько лет до этого Архимед проторчал в библиотеке, выписывая конспекты из книг, составляя памятки, заметки и т.д., история умалчивает — но я предполагаю, что вполне прилично. Интересно, почему Архимед не догадался сделать себе сайт со всеми урлами?
K>Т.е. бесполезно собирать кучу текстов в папочки или набивать память разными методиками. Лучше развивать концентрацию и сосредоточенность.
Хм. Самоулучшение, ниндзя, поза лотоса — это конечно рулез. Но информация-то берется извне, и потоки ее невероятны, линейно упорядочивать информацию ужасно неэффективно, нужна структура: например, дерево или хотя бы какой-нибудь индекс. Я об этом и говорил: информации приходит много, как ее сохранить и удержать в порядке? Как может помочь концентрация, когда мне нужно сделать обзор новых достижений динамической геометрии на сегодняшний момент? Или мне понадобилась теорема из матана, которую мы четыре года назад доказывали? (а она действительно понадобилась, даю слово!) Мне ее как, самому заново выводить?
Отвечу со своей фрилансерской колокольни: КО>Вообще программист наверное должен с приобретением опыта вести такой своего рода дневник, такую личную библиотеку, в которой он накапливает мысли, идеи, решения, алгоритмы, подходы, куски кода, тьюториалы, библиотеки, ссылки, советы, методики и т.д. и т.п.
Мысли, идеи, решения, подходы, куски кода накапливать считаю глупым. Все течет, все изменяется, растет ваш опыт, я надеюсь, и возврат к старому коду, иногда означает и наступание на старые грабли, и использование не всегда самого лучшего решения. Единственное исключение, которое я иногда делаю — если на момент планирования, я могу выделить какую либо подзадачу и решить ее не привязываясь к конкретному приложению, то такие классы я в будущем могу себе позволить использовать, да ито после тщательного анализа (Из-за ошибок в реализации старого класса я раз поимел кучу проблем с новым приложением). По этой причине cut/paste я практически не использую. Специально свои приложения не систематизирую, каждое из них, даже написаные пару тройку лет назад я помню.
Мануалы, экзамплы и библиотеки систематизирую по принципу: ОС->Раздел->Подаздел и т.д. и т.п. Периодически бэкаплю на RW. Если какая-то статья оказалась достаточно полезной, могу законспектировать, и заверстать в LaTeX-е (Есть у меня такой PDF-чик где лежит только то, что мне потребовалось более одного раза). Раз приволок это дело по месту своей основной работы, в университете, накидал html-ок с краткой анотацией и вывалил на наш сервер, народ пищал от удовольствия.
КО>и консервации информации (я имею ввиду: нет же смысла писать, какие пункты меню нужно нажимать, потому что с выходом новой версии это все равно устареет — как выделить нестареющую квинтэссенцию из полученного опыта?) КО>[/list]
Записывать на какие минюхи нужно жать — это вообще маразм. Правильно устроеный интерфейс прозрачен по своей организации, запомните это раз и навсегда. К примеру меню файл обязательно содержит пункт выход, а если вы видите пункты открыть и сохранить, то смело ищите среди менюшек пункт редактировать, где увидите родные и знакомые копировать и вставить. Если же говорить о нетривиальных действиях, к примеру создание какого либо эффекта в PhotoShop, то здесь надо помнить последовательность применения инструментов, а не последовательность кликов по менюхам. Если использовать такой подход, то любая последующая версия вашей любимой программы не вызовет у вас серьезных трудностей. И на последок, если вы не в состоянии уяснить логику интерфейса программы, то возможно эта программа не для вас, ищите ей замену.
Что значит аккумулировать опыт?
По определинию: опыт сам по себе есть аккумулятор. Опыт он эта... сын ошибок трудных ...
Я так понимаю вы хотели спросить как аккумулировать фрагменты кода?
У меня по жизни созрела такая концепция: каждыый проект есть пирамида состоящая из законченных кирпичей.
Т.е. делая проект всегда отдаешь себе очтет что пирамида может не получиться по тем или иным причинам.
Но! Кирпичи-то остаются для следующего строительства! И совсем неумно их каждый раз выбрасывать.
Лично у меня есть два основных "кирпичных поддона" — namespaces gool и tool — графические и общего пользования примитивы.
tool включает в себя функциональные аналоги stl, например. И в тоже самое время это нечто большее чем stl или boost.
Это кирпичи как бы более высокого уровня. Например в tool живет адаптированный persistent storage от Кости Книжника (мое глубокое почтение). Как ultimate solution для сохранения воссттановления состояний. И много чего еще что удалось "окирпичить".
В gool живут dib, png, jpg, gif, hsv, rgb и т.д.
Все это написано или адаптировано (суть изучено) и вяжется друг с другом.
Т.е. это действительно инструменты. И вот это наверное уже продукты опыта.
Т.е. я действительно могу быстро слепить очередную пирамиду в области моего определения.
Таким образом для меня критерий полезности чужого кода — вяжется он или не вяжется в мои tool, gool, html, etc.
— суть станет ли это знание частью моего опыта или нет.
Вот примерно так....
Re[2]: Вопрос-то корректный, название некорректное ;)
Здравствуйте, c-smile, Вы писали:
CS>Вот примерно так....
это вы, Андрей, хорошо, все пояснили.
Думаю подход разумный вполне — у меня по той же причине копится личная библиотечка именем jah (это бог такой растаманский, в пику буржуйскому Локи )
Но тут остается вторая половина Кириллова вопроса: а с доками как быть?
Здравствуйте, c-smile, Вы писали:
CS>Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>>Но тут остается вторая половина Кириллова вопроса: а с доками как быть? ЗХ>>(вот так
. Если рассмотреть подробно этот процесс то можно сказать что есть две фазы:
) 
Можно просто свои ссылки опубликовать на RSDN, и делов. Проблема: если каждый начнет публиковать ссылки, которые он считает нужными, начнутся проблемы — станет тяжело быстро найти нужную ссылку. Хотя, хрен его знает...
Я в бане, а чего больше никто не моется ? 
разумно
