[Uladzimir 93]

Да спору надо. Но не для провокации выставления оценки по нужде.

 

Хотя возможно если так

Возможно первые оценки вообще не учитываются. хотя выставить нужно

Потом, по какому то критерию, например твой ранг перешел какой то порог-- начинают учитываться.

 

Потом вообще получаешь без оценок, если ранг превысил все разумные пределы-- Значит твои компоненты и так приносят пользу, зачем чтоб он еще что либо оценивал.

Захочешь оценишь.. Твои оценки и так на вес золота :)

[vitan 2]

Захочешь оценишь.. Твои оценки и так на вес золота :)

Да, примерно это я описал в посте выше (редактировал, когда Вы уже ответили).

Только у меня более жесткая система. Не "захочешь - оценишь", а "всегда оценивай". Иначе будут возникать "паханы". :) Надо не только зарабатывать репутацию, но еще и поддерживать ее постоянно делами своими. :)

[Uladzimir 93]

Иначе будут возникать "паханы".

О, у "Паханов" система однако еще более жесткая,

Чуть что не так и курлык-мурлы :)

[jkrieger 0]

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

Ну.. управление это очень расплывчатое понятие. Как по мне, то чего ими управлять-то?

 

Признайтесь, Вы решили хранить их по отдельным таблицам только из-за незнания SQL. :)

Ну, это была лишь одной из причин. Есть такая полу-шуточная рекомендация по написанию программ в питоне - The Zen of Python. И там есть строка: Simple is better than complex. В разных таблицах сделать проще. Потому не было смысла огород городить. =)

 

После этого сразу можно будет удалять (или надолго забыть) о длинной таблице параметров, которая там в документе приведена.

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

А вот это уже аргумент! Честно, я как то даже не подумал, что можно сделать параметры динамическими. Как собственно в Альтиуме и сделано. Над этим стоит подумать.

[vitan 2]

Ну.. управление это очень расплывчатое понятие. Как по мне, то чего ими управлять-то?

 

А вот это уже аргумент! Честно, я как то даже не подумал, что можно сделать параметры динамическими. Как собственно в Альтиуме и сделано. Над этим стоит подумать.

Дык это ж и есть управляемость! Вы смотрели таки на скриншот? Видели там пимпочки + и - ? Вот ими все и делается!

 

Т.о. получается, что все манипуляции данными делаются не на сервере админами, а в клиенте юзерами. Это и есть управляемость, гибкость и т.п.

 

А что именно в альтиуме сделано динамически? Там можно создавать некие группы компонентов с переменным количеством параметров что ли?

 

:bb-offtopic:

Simple is better than complex.

Иногда это еще называют KISS. Keep it simple, stupid! LOL

Хотите превратиться в амебу? :) Шутю.

[jkrieger 0]

А что именно в альтиуме сделано динамически? Там можно создавать некие группы компонентов с переменным количеством параметров что ли?

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

Собственно за нас уже давно все придумано, а мы все строим велосипеды.

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

 

P.S. Правда тут ограничение - все параметры будут текстовыми. Либо надо дальше усложнять систему.

Изменено 4 декабря, 2010 пользователем Jack Krieger

[vitan 2]

Там у каждого элемента на схеме есть набор предопределенных параметров (футпринт, модель. описание. комментарий, тип и т.д.), и есть поле параметров, где пользователь жмет кнопочку Добавить и пишет наименование параметра и его значение.

Так это в любом САПРе есть, даже в пикаде. Я же говорю о том, что набор параметров управляется пользователями на уровне библиотек, а не компонентов.

 

P.S. Правда тут ограничение - все параметры будут текстовыми. Либо надо дальше усложнять систему.

Это почему, интересно? В чем трудности-то?

А! Догадываюсь. Непонятно, как хранить параметры разных типов в одних и тех же таблицах. Посмотрите внимательно еще раз на другой скриншот. :) Который со структурой. Там у меня текстовые параметры хранятся в одной таблице, а числовые - в другой. Но это - пока, мне этого мало. В середине топика я уже писал про необходимость усовершенствования типизации. Да, схема данных усложнится, но меня это совершенно не напрягает. Когда мне нужно решение, я его добиваюсь.

Если хотите, можем обсудить типизацию параметров более подробно, мне это интересно. Конкретно интересно, какие типы данных нужны для описания компонентов.

Пока я вижу след.:

- текст;

- число;

- массив чисел;

- частный случай массива - три значения: min, typ, max;

- диапазон;

- условное значение (ток потребления@температура).

Ну и еще нужна группировка параметров в наборы по смыслу (по областям применения): схемотехникам одно, конструкторам - другое... Ну, не буду снова повторяться...

[Uladzimir 93]

Вот я начал новую жизнь.

Что за пару недель получилось.

Тут только директории. Ну они наполнены тем, что я использую.

В моих типоразмерах, сетках и атрибутах

[jkrieger 0]

Доброго дня!

 

Несмотря на череду праздников и командировок, разработка проекта хоть и медленно, но продвигается. Пришло время поделиться с вами результатами и показать очередную версию клиента для проекта (он же Мастер Компонентов).

 

Features:

 

В этой версии есть возможность добавлять новые компоненты в БД на сервере, скачивать компоненты, добавленные другими пользователями, а также экспортировать эти компоненты в таблицы MDB. Настройка экспорта производится в файле 'data.ini'. О том что значат все эти поля подробнее тут.

 

Для участия в ”тест-драйве” необходимо зарегистрироваться тут.

ВНИМАНИЕ! Пароли хранятся в открытом виде - не используйте свои личные пароли.

Эти логин и пароль необходимо будет указать в секции [ACCOUNT] в файле 'pyclient.ini', также там можно настроить прокси, если нужно. Можно конечно и не регистрироваться, а использовать демо-аккаунт 'user/user', но так ведь неинтересно ;-)

 

Все действия на данный момент совершаются вручную при помощи четырех кнопок:

Add - добавление нового компонента (во внутреннюю БД)

Download - загрузка новых компонентов с сервера (во внутреннюю БД)

Upload - отправка новых компонентов на сервер

Export - генерация MDB файла, предназначенного для подключения к CAD.

 

Назначение остальных элементов управления думаю понятно из надписей.

 

Пока что программа не умеет передавать файлы на сервер, поэтому небольшой набор символов и футпринтов прилагается в архиве с программой в папке 'export'. Там же и демонстрационная библиотека user.DbLib, которую можно подключить к Altium.

 

Known issues:

 

- клиент не умеет обновлять записи в БД: если компонент с таким именем уже существует, то новый добавлен не будет;

 

- не реализовано создание корпусов, символов и моделей: пока что, выбирая символ, корпус или модель, вы выбираете соответственно лишь файл SchLib, PcbLib и .mdl / .ckt. (однин на компонент);

 

- поддерживаются только текстовые параметры, т.е. все числа все равно будут текстом (вроде бы сделать несложно, но в результате многократно перекраиваемой архитектуры приложения я в ней уже запутался =) );

 

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

 

- наименование опций в '.ini' файлах нужно писать в нижнем регистре, а названия секций - в верхнем.

 

 

Future:

 

Сейчас уже стало понятно, что в том первоначальном виде проект нежизнеспособен. Напомню, раньше планировалось, что данные о компонентах будут храниться в базе данных MySQL на сервере noxius.ru (как это сейчас и сделано), а файлы (символы, футпринты, модели) - под системой контроля версий (mercurial) на хостинге Google, и передаваться соответственно при помощи своего клиента.

 

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

 

Отсюда вытекает два варианта:

 

1. Хранить файлы на том же хостинге, где MySQL база (noxius.ru) и передавать их самим клиентом (Мастером Компонентов).

 

В этом случае нам нужно научиться передавать файлы от пользователя на сервер и обратно (написать этот функционал).

Кроме того, как показала практика, нехватает некоего Менеджера Компонентов, где пользователь мог бы просматривать весь перечень компонентов, символов, корпусов и моделей, которые у него есть в распоряжении, редактировать их, проверять; и инструмента для сравнения двух версий компонентов.

 

2. Хранить все данные под контролем версий на Google Project Hosting (или может github).

 

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

 

Управление своей библиотекой сведется к тому, что вам нужно, используя инструментарий TortoiseHg, получить у себя на диске необходимые вам версии файлов (xml + CAD's). А Мастер Компонентов из этих файлов сгенерирует вам CSV-файлы или MDB-таблицы для подключения к CAD.

 

К минусам такого подхода относится высокий уровень входа. Для новичков mercurial может оказаться непонятной и сложной системой.

 

 

 

Лично я склоняюсь ко второму варианту. Мне кажется что распределенные системы контроля верий (mercurial, git) вполне подходят для создания открытой библиотеки компонентов.

 

Спасибо, что дочитали. Хочу услышать ваше мнение по какому пути следует двигаться?

[Krys 2]

Мы здесь что-то стараемся, обсуждаем. А люди уже во всю выпускают: http://www.rodnik.ru/news/index.php?ELEMENT_ID=1275

Возможно, и наши идеи там оказываются помаленьку.

[Uladzimir 93]

так этой новости старше лет, чем началу обсуждения этой.

мое мнение :(

По библиотекам-- ко мне столько приходит, и проверенных-- иногда пользуюсь в части Footprint и только.

А так все равно доработка.

Вот если IPC или ГОСТ выпустит и скажет юзать только такое-- и то не пойдеть.

 

 

 

[vitan 2]

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

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

[Uladzimir 93]

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

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

Ну да. Но рано и ли поздно энтузиазма не хватит.

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

Иначе тоже никакого развития :(

Бесплатный сыр только в мышеловке

[YUDSV 0]

Добрый день.

Подскажите, пожалуйста, как зарегистрироваться для участия в ”тест-драйве”. При нажатии на "тут" - не понятно куда отправляют.

Всех с Рождеством!

:santa2:

[jkrieger 0]

YUDSV, я извиняюсь что так поздно отвечаю. Работа над проектом сейчас правктически не ведется. Хотя я пользуюсь этими репозиториями и мастером компонентов. Если еще интересуетесь, можем попробовать вместе.

 

Для работы вам понадобится гугл-аккаунт (если его нет, то что-нибудь придумаем), tortoisehg и ознакомиться с терминологией и идеологией системы контроля версий mercurial. На английском хорошо описано здесь. На русском нужно поискать. Можно почитать, например, вот эту статью.

 

А также необходимо скачать мастер компонентов для данного проекта. Назначение, принцип его работы, а также ссылки для скачивания - в статье на we.easyelectronics.ru.

 

По всем вопросам можете писать мне на jack.krieger(at)gmail.com