КВБ>Вишь поиск какая классная штука, ничего не аккумулировал а информацию достал.
p.s. он в инете сам по себе аккумулируется. Как что хорошее появляется оно тут же расползается по куче сайтов.
Остается только научиться пользоваться поисковыми системами.
Эх, cкоро на свободу. Сидеть осталось 28 дней. Я в бане, а чего больше никто не моется ?
[зверьковыгрызено]
Поддерживаю.
Господа хорошие, поиск — это конечно гут.
Однако ж я вот допустим осваивал новый язык Перл (это к примеру). 2 дня поиска по инету дало мне около 5 полезных эл. учебников и штук 30 статеек — некоторые полезные. некоторые не очень. В данный момент все эти поиски объяснялись только интересом, но, допустим, через 2 месяца (года, десятилетия) я вдруг захочу писать на Перле. И что? Опять 2,3 дня, неделю искать инфу? или зайти в папочку Перл на диске?
Помимо тог Буч, Кнут, Страуструп, Рихтер, Вандевуд... кто-то откажется от книжек с anatolix.naumen.ru?
А таких книг не так уж и мало, чтобы все сложить в одну папочку и юзать.
Кроме того... если я уже с этой задачей справился, найдя доки, то почему, встретившись с ней через 3 года, я должен опять перелопатить пол-инета (где, может быть. и сат-то уже закрылся), а не запустить поиск по своей базе, в которой это ТОЧНО ЕСТЬ и будет найдено (причем не среди 10^10 ссылок с теми же ключевыми словами, а именно то. что я хочу?)
По-моему, это какое-то излишне легковесное отношение к опыту — нашел раз, найду и еще раз.
(Все то же самое, и в существенно больщей степени, касается кода)
Я например использую следующие вещи:
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>Просто Библиотеки сохраняют ключевую информацию в нашей цивилизации. И мне просто нет смысла дублировать их работу.
дык... если я — разработчик ПО, то мои основные инструметы — это знания.
тут по ананлогии с мастерской — можно, кончено, каждый раз у одних знакомых одолжить пилу, у других — молоток, у соседа — дрель.
но если тебе приходится работать в мастерской часто, ты не поленишься оборудовать ее так, чтобы все было удобное и под рукой.
вот.
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>Здравствуйте, Vasili Trifonov, Вы писали:
VT>>Просто Библиотеки сохраняют ключевую информацию в нашей цивилизации. И мне просто нет смысла дублировать их работу.
ЗХ>дык... если я — разработчик ПО, то мои основные инструметы — это знания.
Конечно.
Но при этом: Что толку от знаний которыми ты не пользуешься [никогда не будешь пользоваться]? (C) Дон Хуан. Я именно это и имел ввиду.
У меня скажем бесценный в свое время ксерокс книжки Чарльза Петзольда про Programming Windows 3.1 сейчас уже второй месяц обслуживает туалет у кошки. Такова жизнь
Здравствуйте, Vasili Trifonov, Вы писали:
VT>Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>>Здравствуйте, Vasili Trifonov, Вы писали:
VT>>>Просто Библиотеки сохраняют ключевую информацию в нашей цивилизации. И мне просто нет смысла дублировать их работу.
ЗХ>>дык... если я — разработчик ПО, то мои основные инструметы — это знания.
VT>Конечно. VT>Но при этом: Что толку от знаний которыми ты не пользуешься [никогда не будешь пользоваться]? (C) Дон Хуан. Я именно это и имел ввиду.
никто ж не спорит. но ты ведь не отрицаешь, что кучу енужных и полезных знаний надо все-тки как-то стуктурировать?
Здравствуйте, 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 уделить на то, чтобы подумать: может ли это понадобиться мне или моим знакомым в будущем? Если есть такая возможность, положить ее в архив (за логарифмическое время!)
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>никто ж не спорит. но ты ведь не отрицаешь, что кучу енужных и полезных знаний надо все-тки как-то стуктурировать?
Нет конечно. Но тут спасает простое структурирование по иерархии директорий. Причем иерархия выбирается максимально простой.
Но все равно получается достаточно сложной, у меня только библиотека книг содержит порядка сотни папок по разным тематикам а есть ведь еще инсталляции, примерчики, итд.
Кстати на эту тему уже здесь хорошо высказались.
И кстати, если вы (на пару с Кириллом) напишите какой-нибудь удобный каталогизатор, я буду рад им воспользоваться и предложить кучу полезных идей с точки зрения его пользования. А опыта уж хватит — с 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). При генерации можно было бы выбрать таблицу стилей (например, украденную с РСДН — очень уж она мне нравится )
уже. в идеале и будет возможность генерить что-то вроде РСДН — слева деревце, справа вверху — книжки в текущей папке, справа внизу — описание книжки и БОООЛЬШАЯ кнопка Загрузить
ЗЫ: все "уже" значат "уже запроектировано" а не "уже написано"
Я в бане, а чего больше никто не моется ? 
)
)
разумно
. вскрытие покажет.
