Товарищи! Я тут подумал... может конечно оно зря/либо эта идея уже обсуждалась/либо вы уже сами насчёт этого думали!

А тема такая - есть DRKB! А неплохо былобы в дополнении к DRKB что-нибудь типа DRSCB-delphi russian source code base.
Тоесть илсходники и компоненты все туда обьеденить, и использовать это как примеры... ну или как уже готовые компоненты.
Или например свою палитру компонентов сделать... которая будет включать всебя наработки винградовцев и других. Я думаю много кто полезные компоненты делал... главное что может помешать - нежелание делиться своими домописными компонентами!

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

З.Ы. не бейте меня сильно если тема обмусолена была уже...

Вообще идея конечно неплохая...
Но на сайте torry.net уже и так компоненты со всего света - столько
еще ни где не не видел

Неплохо бы просто по исходникам различных интересных программулин...

Да... На torry.net действительно много компонент... Но нет таких, которые мы пишем в домашних условиях?

Может начнем продвигать эту тему?

А в чём проблема? Кто мешает взять и создать такую штуку?

Вообще, то статьи исходники примеры - это все хорошо - но отлаженные компилированные компоненны (или даже библиотеки компонент с helpom на русском языке (размечтался:hehe)) куда полезнее.
Вот только работы здесь много...
Кто-то должен проверять сортировать заменять старые версии...
Добавлено @ 16:00
Vit проблема в том чтоб сделать это в рамках сайта vingrad

А лучше каждый бы по одной Win Api функции из SDK перевел на русский язык пользы бы больше было.

MIX55 одно другому не мешает организуй - будем помогать
по крайней мере на меня можешь расчитывать.

В деле перевода SDK помочь готов. Только не все

Работа над этим уже ведется:
http://forum.vingrad.ru/index.php?showtopic=80590

А еще лучше, выучить английский, забыть про проблемы с SDK и вправду заняться компонентами

Много функций да

Что касается переводов SDK, то не занимайтесь ерундой, лучше учите английский. На счет базы исходников, то в FAQ форума есть раздел для публикации исходников, выделите одного или двух людей ответственных за раздел и обратитесь к ведущему FAQ я думаю он с радостью даст вам доступ на добавление в этот раздел, а тот кто хочет, что бы его компоненты или исходники были опубликованы, пусть добавляет их в тему "Арсенал форума", а ответственные отслеживают эту тему и все корректно переносят в раздел FAQ или можно сразу присылать свои компоненты ведущим раздела, что бы они их опубликовали.

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

http://forum.vingrad.ru/index.php?act=modu...amp;section=505

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

Alex раздел FAQ лучьше пусть так и будет с факами, свои мини програмки я думаю лучше выкладывать в одно место, свои супер-пупер написанные функции для работы с чем-то в другую тему, а свои компоненты - в третью... так будет путаницы меньше...
Главное все упорядочить, для оптимизированного поиска... ну и правильно ты сказал - кто-то должен отслеживать все приходящее и выкладывать в сооветствующие разделы...
Я думаю плохо, если будет всё валить в один раздел, чтобы модер разбирался чё куда... будет же настоящая свалка исходников+будет дублирование всего по темам!
Над этим вопросом придётся подумать!

З.Ы. про SDK я вещь поддерживаю, особенно чтобы примеры были, а то эти Borland&Microsoft примеры такие бывают тупые/ либо не понятные

Ребята, я когда такое слышу у меня такое чувство, что мы с вами на разных планетах живем, на разном языке пишем программы и у нас с вами разные поставки Delphi. Уж кто бы жаловался на отсутствие примеров? Delphi вам поставляется с исходными кодами элементарный поиск по вхождению названия функции в pas файлы лежащие в папке "X:\Program Files\Borland\DelphiX\Source\" даст вам столько примеров использования функций, что ни одному SDK не приснится. При этом вы получите реально рабочие примеры, а не какие-то надуманные ситуации. Теперь что касается Microsoft извините, но человек занимающийся программированием под Windows обязательно должен иметь на компьютере MSDN или хороший канал интернет что бы посмотреть ее on-line версию. Теперь что касается чтение MSDN лично я считаю, что английского не знаю во все, но прочитать и понять, что написано в 2-3 строчках описания функции в MSDN после года ее постоянного использования я думаю в состоянии любой, если нет, то программы "Переводчики" ни кто не отменял. Если нужны примеры функций, то опять банальный поиск по исходникам даст вам куда больше примеров, чем будет написано в любой документации. Я лично JCL и JVCL держу на машине практически только из-за кландайк примеров использования функций.

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

PS:
Мой вам совет прежде чем писать вопросы говорить, что ничего нету посмотрите во круг себя и вы поймете, что 60% информации уже лежит у вас на компьютере и ждет пока ей научатся пользоваться.

По поводу MSDN, полностью поддерживаю мнение Alex'а.
Тем более, что индивидуальный перевод по 5-10 функций приведет к полному бардаку. Если уж переводить, то нужно что-бы один человек перевадил целый раздел. Иначе, из-за разницы перевода неустаканившихся терминов, будет невозможно чего-либо понять. Кроме того, для этого требуется жесткая координация, опять для унификации терминологии и и налаживания перекрестных связей. Без оных, ценность такого перевода невелика.
А потом, кто будет проверять правильность перевода? Уже не раз сталкивался с попытками перевода тех или иных хелпов, включая разделы MSDN. Так вот, большинство из них, страдает тем что переводчик не уделял достаточного внимания мелочам и нюансам. Либо вообще ошибался при их переводах. Лично я, чаще обращаюсь к MSDN именно для выяснения нюансов и особенностей тех или иных функций. И реже для знакомства с архитектурой и идеологией тех или иных технологий. Что-же касается краткого описания функций, то уже через 2-3 месяца пользования, английский язык будет Вами освоен в достаточном объеме. Достаточно иметь под рукой словарь, желательно электронный, с переводом через клипбоард. Тем более, он все равно пригодится, одним MSDN источники информации не ограничиваются.

Что же касается библиотеки компонент и функций, то тут тоже сильно сомневаюсь.
Кто нибудь из сторонников этой идеи пользуется библиотеками JCL и JVCL? Если нет, то вам дорога туда. Если да, то вы дожны были уже понять всю безсмысленность данной идеи.
Лично у меня есть своя библиотека, формирующаяся исходя из моих потребностей. Реальных пользователей у нее всего 3,5 человека - это мои коллеги. Более чем уверен, что большая часть функций пересекается с такими-же функциями других программистов. Ну и кто это все будет интегрировать? И что потом меня заставит переделывать свои программы на новые интерфейсы? Тем более, я их должен буду сначала изучить и освоить. Естественно я останусь на своей библиотеке, и буду продолжать развивать/исправлять/изменять именно ее. А кто будет тогда переносить мои изменения в интегрированную?
Я не зря упомянул уже JCL и JVCL. Они рождались именно по этому пути - разработчики интегрировали туда огромное число разработок разных программистов. И к чему это привело? Монстр, который для новичков не годится из-за отсутствия толковых описаний, а для проффи, из-за своей громоздкости в результате которой, часто бывает проще начирикать свою функцию, чем искать нужнуж в JCL&JVCL.
А вот как ОГРОМНАЯ библиотека примеров - эти библиотеки очень хороши.

Только на начальном этапе программирования человек будет целиком потреблять универсальные библиотеки. С ростом квалификации, он постепенно уходит от больших и унивирсальных библиотек. Остаются только несколько небольших специализированных, типа EhLib'а, FIB+, FastReport, ...
Класический пример это RxLib. С нее начинали многие. А поскольку она сочетала в себе достаточно функцианальность с компактностью и хорошей документированностью, то она жива, и популярна до сих пор! Кстати, то что ее развитие ее было заморожено, сыграло только на руку ее популярности - она не превратилась в монстра.
А что касается собственных разработок, то для того что-бы ими могли воспользоваться другие, они должны проникнуться принятой у меня философией программирования. Например, для сигнализации о возникающих ошибках почти всегда использую механизм исключений. А многие программисты приходят к этому лишь спустя несколько лет. Поэтому, попытки воспользоваться моей библиотекой со стороны начинающих пользователей чаще всего вызывают не понимание как этим пользоваться. Лишь много позже, когда они уже давно отказались от ее использования, они сам приходят к этой философии. Но, к этому времени, они уже имеют свою библиотеку.
Причем, я часто включаю в свою библиотеку интересные чужие разработки, естественно переделывая их под свою философию.

Я вот не согласен с ВамиПетрович. Что значит краткого? Надо полного и чтобы с примером (рабочим). А если кратким то кому это нужно в инете полно описаний функций. А вот конкретный пример полного перевода функций и пример работы с ними:здесь человек постарался не для кого то а для себя любимого и все пользуются и всем хорошо. Взять хотябы проект DelphiWorld или DRKB спросите кто их не знает? и как они помогают в поиске информации.

насчет оформления создать определенные правила.

если к примеру ктото нашел недочеты или не правильную трактовку обсудить на форуме и заменить. Для чего же нужно "тестирование".

MIX55, давайте не путать FAQ и перевод SDK

имелось в виду что хуже от этой затеи никому не будет.

Как это не обсурдно звучит, но это не факт!.
Например, даже во всеми любимом DRKB, встречаются такие ошибки в примерах, которые не всякий программист заметит. Уже тем более малоопытный программист. Более того, несмотря на то что большинство примеров проверялись создателями (чаще это даже продукт жизнидеятельности автора), эти ошибки там остались - это как раз те нюансы которые автор не учел, порою по незнанию. Эти ошибки зачастую могут всплывать у потребителя в самый неподходящий момент - потом, он долго "прыгает" выискивая в чем проблемма.
Более того, например встречал такой не то FAQ, не то еще что-то, очень широко распространенное. Так там вообще обнаружил довольно много не просто ошибок, а очень грубых ошибок, я бы даже сказал "ложной информации" вводящей в заблуждение читателей!. Знаю даже нескольких программистов-новичков которые были воспитанны на этом FAQ. Так они даже пытались со мною спорить о том что я не прав, говоря что "уважаемый автор так написал, значит это так".
Конечно, ответят мне, можно постепенно исправлять такие ошибки. Но, на самом деле, это не так легко как кажется:
1. Часто, обнаружить и исправить такие ошибки могут лишь опытные программисты, а они редко заглядывают в такие документы.
2. Для удобства пользования, такие документы (справочники) делают доступными для автономной работы. Соответственно, большинство пользователей "заводят" себе локальную копию такого документа. Следовательно, нарушается целостность. Т.е., если в основной документ на сайте будут внесены исправления, у пользователя они появятся только после того как он вновь загрузит его с сайта. А ввиду большого размера, делается это не часто. А делать подгрузку только изменений, тоже далеко не тривиальная задача. Например, было уже несколько попыток сделать подобное для DRKB, однако энтузиазм у авторов таких средств как-то быстро угасал .
Кроме того, промежуточные версии таких документов имеют тенденцию "расползаться" по инету, локальным дискам, и сидиромам. Поэтому, взятые не из первоисточника, всегда будут отставать по адекватности от оригинала, и читатели даже не будут знать что те или иные разделы давно уже исправлены.

Да, я параноик. Можно подумать что я считаю что лучше ничего не делать чем пытаться как то помочь людям. Это не совсем так. Я лишь твердо считаю, что такую важную информацию лучше черпать из первоисточника - MSDN. Конечно и он не безгрешен. Он тоже обновляется и дополняется, поэтому лучше если это MSDN online. По крайней мере, не стоит вносить еще дополнительные неточности и ошибки, их уже и так достаточно делает Microsoft.
Кроме того, по моему мнению, лучше когда нет информации, чем когда она заведомо недействительная.

А что касается не простоейших, а полноценных примеров, то тогда, нет ничего лучше знакомства с текстами реальных "боевых" программ. А полноценные примеры во многих случаях прото невозможно сделать ввиду сложности. Многие функции требуют серьезной обвязки, среди которой суть использования описываемой функции просто затеряется. Например, напишити-ка реальный пример использования функции проверки электронной подписи на Windows Crypto API. Так для того что-бы понять такой пример, придется полностью разобраться в архитектуре Windows Crypto API, сертификато и т.п. Да и размер этого примера будет огого, если он конечно будет способен автономно работать Причем, непосредственно демонстирируемая функция будет там занимать около 1% - поиди найди .

Но, еще раз повторюсь: "Это мое личное мнение, основанное на моем личном опыте". Если есть желающие - пожалуйста, флаг вам в руки.
Добавлено @ 13:10

Да, пример хороший. Я тоже могу привести много таких примеров. Но, это статья написанная профи которому я доверяю - благо я его знаю . Но, я также могу привести примеры (лень вновь их искать) которые тоже похожи на профессианальные, однако несут в себе больше ошибок чем истины . Если не знаешь автора, то как определить степень доверия к его информации?
Профи не часто беруться за такие работы. Только когда есть вдохновение и время. Их порою даже за деньги на такое трудно сподвигнуть .

Это сообщение отредактировал(а) Петрович - 26.1.2006, 13:00

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

Что касается, качества информации присутствующей в FAQ, то могу сказать так: я в течении года занимался тем, что с еще рядом людей переводил DRKB в on-line версию FAQ форума, сейчас в FAQ экспортировано около 95% DRKB и за этот год в DRKB было найдено не мало не точностей или просто не рабочих кодов, всего около 100-150 тем, все эти вещи конечно, правились в on-line версии, некоторые темы дополнялись новыми примерами. Теперь существует двоякая вещь по-хорошему нужно найти и исправить все эти вещи в DRKB, но как? Делать это в ручную не представляется возможным (общий объем информации более 2500 статей), при этом сейчас активно тестируется программа просмотра DRKB с возможностью подзагрузки обновлений, но ребята опять взяли за основу chm, файл, в котором не исправлены ошибки , и что-то мне подсказывает, что они не последние кто его взял за основу.

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

А самое главное, что с годами вы все чаще будите сталкиваться с ситуациями, когда вы будите понимать, что ответить на вопрос как что-то сделать можете только вы, т.к. это ваша задача и вы знаете уже столько подводных камней и столько вариантов решения перебрали в голове, что если при задании вопроса описать все нюансы, то это целый доклад получится И как следствие найти ответ ни в одном FAQ вам не удастся. Лично у меня это сейчас 40% задач (которые ежедневно решаются с помощью комбинации накатаных годами схем решения и знаниями, которые трудно описать), еще 20%, это уже давно написанные куски кода, которые были в других задачах написаны и сейчас перекачевали в некую собственную библиотеку функций (но без должного описания половина их бесмыслена для общественности) и 40% это конечно изучение новых вещей. А вот тут уже извините, но не один FAQ не даст мне столько сколько дает поиск по всем доступным источникам. Методика поиска практически всегда одна:
1. В исходники Delphi или сторонних библиотеках
2. Если помню, что такое упоминалось в DRKB или теоретически там может быть, то поиск по уникальному слову задачи там (уникальное слово выбирается или название функции или одного из ее параметров, не нужно задавать для поиска слово "File" в попытке найти информацию как создать файл ). Но в обще так вышло что в связи с переводом DRKB в FAQ я знаю, DRKB практически в доль и поперек (нет конечно я не помню содержание всех статей, но заголовки помню практически все и практически без ошибочно определяю есть информация по какому-то из вопросов в DRKB или нет )
3. Поиск по форуму
4. Поиск с использованием Яндекс
5. Поиск Google. Обходился бы без 4 пункта, но то что в Google при нажатии на ссылку она открывается в том же окне очень лично мне не удобно (может не знаю как настроить). Хотя часто результатов поиска Яндекс мне хватает
6. Книга, но за последние 2 года этот пункт относится только к информации по БД Firebird (книги просто всего 2 выпущено, по ней на русском языке, но действительно стоящих)
7. Самый главный! Анализ всей найденной информации, комбинация найденных решений, адаптация под свою задачу, внедрение в программу.

Второй пункт, что касается функций WinApi заменяется поиском в MSDN.

Это сообщение отредактировал(а) Alex - 26.1.2006, 14:37

А что за книги по БД Firebird, если не секрет?

Firebird. Руководство разработчика баз данных Автор: Х. Борри
Мир InterBase. Архитектура, администрирование и разработка приложений баз данных в InterBase/Firebird/Yaffil. 4-е издание Авторы: Алексей Ковязин и Сергей Востриков