Стартуем разработку

И снова здравствуйте. Так как предыдущая тема скатилась, что и предполагалось, в холивар относительно языков программирования/документации, то в этой теме предлагаю высказаться все таки по теме разговора. На текущий момент концепция софта предполагается следующая:

— разработка клиента на Unity3D, портирование под мобильные платформы. Серверная часть — на ASP.NET, скорее всего просто хэндлерами, так как не уверен в работоспособности веб-сервисов под мобильные платформы, но пока вопрос открыт. Да и не столь критичен — транспортный уровень, в конце концов, поменять труда не составит.
— языки программирования клиента — C# + JS, сервер — C#
— клиент предоставляется бесплатно, по крайней мере для ПК. Существенным преимуществом считаю доступность клиента без платежей, так как это одна из причин тихо шипеть на другие решения
— развитая база компонентов, предоставляемая в режиме On-line. Возможность добавлять компоненты самим пользователям. Предмодерация компонентов, чтобы они не скатились в говнище типа вики, так как заказать даже десяток плат опытного производства и узнать, что кто-то пошутил — означает поставить крест на проекте.
— база даташитов.
— база типовых схем реализации блоков устройств.
— адаптация под сенсорное управление.

Софт, скорее всего, будет запускаться через лаунчер, так как некоторые функции (такие, например, как работа с pdf) в юнити очень слабы.

Чего хотелось бы:
а) понять, чего не хватает в готовых решениях
б) понять, готов ли кто то участвовать в написании клиента/сервера.

Что касается участия — то я противник того, чтобы бесконечно обсуждать крутость проекта в скайпе. У меня был подобный опыт, 3 мес мы не могли начать — нахер. Кто готов участвовать — открываю доступ к свн проекта. Если в течение длительного промежутка нет никакой активности — удаляю акк, извините. Старт работ в юньке — понедельник, так как потребуется время на перенос исходников из старого проекта и адаптирование их под движок, ну и плюсом нужно вспомнить некоторые моменты.

Сознательно не поднимаю вопроса относительно коммерческой составляющей. Еще раз повторюсь — я делаю это ради идеи/скиллов/приятного времяпрепровождения. Как срубить бабла — ИМХО, еще один крест на проекте.

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

Спасибо.
  • -3
  • 31 января 2013, 17:03
  • dtcDev

Комментарии (133)

RSS свернуть / развернуть
какие-то злые требования про svn. А если я просто хочу посмотреть на исходники и понять — буду я в таком участвовать или нет? Зачем удалять акки? Вдруг я найду время через пару месяцев что б пописать?
Почему не git и не github, где можно найти дополнительную помощь в виде сообщества?
ну и да — портирование на мобильные клиенты тут, вроде, лишнее. Пробовали пользоваться CAD на мобильном? Лучшим считаю EveryCircuit, но и им пользоваться кроме как для поделок до 10 компонент невозможно…
0
Докладываю.
С свн драконовские правила потому, что хочется найти единомышленников. Если человек отвалился, то он потратит много рабочего времени других участников проекта на то, чтобы выяснить, куда успел убежать проект, пока он отсутствовал.

СВН — потому что так проще и быстрей, имхо.

Мобильные — не скажите. У меня планшет с 1280 на 800. Думаю, что на нем протыкивать руками плату/схему гораздо быстрее и приятнее, чем мышой на компе. Хотя могу и ошибаться. С другой стороны — если есть возможность — то почему нет.
0
ошибаетесь — у меня планшет с 2560 на 1080 и ни фига не удобно. Вот даташиты и схемы глядеть удобно, а делать нет.
0
Дык эти мобильные кады, а именно интерфейс, делались с мыслью о мышке и клавиатуре, а думать то нужно было о пальцах. Например проблема — попасть в пин и протянуть линию к другому элементу, так вот вопрос: зачем попадать? Вариант: ткнул в элемент — появилось менюшка с именами пинов — выбрал нужный — ткнул в то куда подключить (другая деталька, проводник, шина) там тоже появилась менюшка со списком пинов или вопросом к какой цепи подключить / создать новую или подтверждением что хотим подключить именно сюда и получаем линию соединения с наименьшей длинной, далее с некоторым гемороем порастаскивать получившийся пучек проводников, хотя в случае с шиной (схема больше 10 деталек) и растаскивать особо не прийдется.
0
еще большую херь еще менее юзабельную предложил.
0
плюс, автоматическая прокладка связе — нах-нах, выйдет такая-же херь, как и авторутеры.
0
IMHO, вывести две альтернативные возможности — формирование за счет классического «клик в пад» и формирование за счет контекстного меню
0
А зачем закрывать разработку? Подними публичную разработку на гитхабе. Он заодно позволяет приходить с запросом «а дайте мне доступ на запись» уже не с пустыми руками, а своим форком.
+1
  • avatar
  • Vga
  • 31 января 2013, 17:31
Как вариант
Читаю.
0
Кстати да, присоединяюсь.
0
+1
0
Во-первых, предлагаю по серверной части забить на дот-нет и взять жабу. Под нее существует просто немерянное количество готовых решений, которые можно взять за основу и навернуть сверху свое. Думаю, на сегодняшний день в плане количества и качества таких решений с жабой тягаться трудно, если вообще возможно. В добавок практически все, что представляет интерес идет под апачевской лицензией. Во-вторых, не нужно делать раздельных баз. База должна быть единой со сквозным поиском и (кросс)индексацией. И в базу нужно иметь возможность ложить не только компоненты, но и готовые разработки (открытые/расшаренные/полностью приватные). Ну и открытый API для доступа к этому всему добру, конечно.
Возможный вариант хранилища — github.com/tjake/Solandra/wiki/Solandra-Wiki, перед этим полезно почитать про Cassandra, Solr, Lucene.

P.S. возможный вариант монетаризации — корпоративные «песочницы» для разработки. хранение личных разработок должно быть бесплатным
0
  • avatar
  • evsi
  • 31 января 2013, 17:50
Solandra — не обкатанный продукт (или у Вас был опыт эксплуатации), да и объемы информации далеко не те, на которых нужно «highly scalable real-time search engine». Если мы говорим о БД до 1кк записей, то даже банальный mysql справится без доп.индекса в виде той же Lucene.
0
У меня был опыт эксплуатации кассанды и люсина поотдельности. Запихать хранилище в кассандру вполне логичное решение и делается штатными средствами люсина + штатными средства кассанды. И нет, я ни в коем случае не хочу использовать mysql для этой задачи. Тот случай, когда ему тут не место. Совсем. Как только вы в него начнете ложить много данных (скорее по размеру), тут же вас ожидает немерянное количество проблем. О масштабируемости я вообще молчу. Кассандра+люсин это, IMHO, опитимальное сочетание. Да, возможно применение и других хранилищ, тот же оригинальный Solr, к примеру. Но с Hadoop-ом лично дела не имел, а мои коллеги отзывались без особого восторга.
0
Я работаю в Яндексе и имею представление о больших объемах данных, спасибо :)
0
Пожалуйста. Но в таком случае я не понял смысла вашего предложения насчет mysql. Во-первых, компонентов явно счет идет на миллионы. Во-вторых, это реально большие объемы (описание+даташит+ссылки на уго+etc). В-третих, это, преимущественно, бинарная информация непредсказуемого размера. Все вместе — совершенно неудобные данные для mysql.
0
Блять, товарисчи!!! В личку, плиз! или в старый тред!
+1
отвечаю.
поиск практически всегда будет идти только по названиям компонент (не представляю поиск по описанию или еще чего) — с этим справляется любая СУБД даже при миллионах записей
второй аспект — подбор по параметрам. Тут сложнее, но выбор, обычно, в рамках категории, например: транзюки. А значит записей уже не миллионы. Параметрический поиск может и хромать на mysql, но надо смотреть более детально. Максимум — можно добавить доп. индекс в виде Lucene, о чем я и говорил
Все даташиты удобнее хранить в pdf на файловой системе

В любом случае мое сообщение должно сводиться к тому что чем проще система, тем проще ее поддерживать и развивать. KISS
-1
поиск практически всегда будет идти только по названиям компонент
Нет. Если вам доводилось хоть раз искать компоненты с нужными функциями и параметрами, то вы должны знать, что зачастую название не известно. Как и производитель.
Все даташиты удобнее хранить в pdf на файловой системе
Угу. И файловая система обеспечит вам надежное хранение и нужный уровень избыточности? А так же индексацию контента?
В любом случае мое сообщение должно сводиться к тому что чем проще система, тем проще ее поддерживать и развивать. KISS
Именно. То, что вы предлагаете только усложняет систему. Раздельное хранение это, как минимум, необходимость поддерживать целостность двух разных баз, что как бы, совсем не простая задача в распределенной среде, даже если обе поддерживают транзакции. А тут ФС. И с поиском у вас сразу возникают заморочки. А тут это все искаропки.
0
Следующий пост пойдет ридонли, общение с заинтересованными — только в личке.

Я конечно понимаю, новая площадка, не надо скролить по полчаса до сообщения. Айда зафлудим и тут к хуям собачьим все что можно
0
все-все — я перевел в личку общение. Примите извинения :)
0
спасибо!
0
для ридонли заведи свой сайт и общайся там.
имхо, именно открытое обсуждение и есть залог успеха всяких там сообществ.
0
спасибо, уже завел.

Открытое обсуждение — да. Открытый срач на тему языков программирования, который превратил в нечитаемое гавно прошлый топик — ничего полезного не принесет
+2
ну, без срачейдружеского обсуждения никуда.
тут путь один — своя площадка и модерирование.
0
Никого не принуждаю — соседняя тема в полном распоряжении. Тут же хотелось бы перейти от того, на чем делать, к тому, что делать.
0
ну, лично мне чуть более чем полностью однох… о монопени… о без разницы данное начинание. свое отношение я выразил в первом комменте в той теме.
ну, будет очередной велосипед, который будет жить пока сохраняется интерес у разработчика. так же тихо умрет. и никакого влияния на индустрию не окажет. просто вы не видите многих организационных (а совсем не технологических типа языка или используемой БД) проблем, без решения которых подъем проекта подобного масштаба (если верить поставленным целям) немыслим на голом энтузиазме.
0
Возрадуйтесь своему отношению и перестаньте флудить
0
и перестаньте флудить
воззваниями этого не добьетесь.
это зависит только от моего настроения. ;)
-1
кстати. невзирая на форму, по факту у вас есть что возразить?
без подколок спрашиваю.
0
Следующий пост пойдет ридонли, общение с заинтересованными — только в личке.
Ничего хорошего из этого не выйдет.
0
Боюсь, что от срущих в карму следующего поста не будет. И «ничего хорошего не выйдет» — почему? Если каждый пост скатывается к обсуждению C#/C++/Java/Delphi/хз — против чего собственно и протестовал — то?..
0
Ну хотя бы потому, что без комментариев пост никто и не заметит. А кто заметит — положит еще минус, за отключенные комментарии.
Карму подправил, но публиковаться в личном блоге никакой минус не помешает.
Что до срачей — просто не обращай внимания. Вылавливай только полезные замечания. Ведь именно по итогам того обсуждения ты пришел к варианту на Unity3D.
+1
Вот тут Вы совершенно правы. Я многое почерпнул в процессе обсуждения, равно как и нашел единомышленников. Просто не обращать внимания на холивары вокруг языков программирования становится трудно, когда они составляют 99% всего обсуждения.
0
Еще раз хочу отметить. что я не хочу сваливать этот тред к очередным холиварам на тему «а на чем же нам писать». Посмотрите прошлый — 200+ постов, черт голову сломит.

ASP.NET
0
ASP.NET
Нафига изобретать велосипеды?
0
Да, что касается монетизации — тут я с Вами согласен. Для конечного потребителя все должно быть бесплатно, иначе то же существующее решение, только в профиль. Это основа концепции.
0
С такими жесткими требованиями, например ядро Linux, никогда бы не продолжило развиваться. Некоторые могут принести пользу в отдельных блоках и модулях, им незачем знать весь проект. Порой хорошую мысль приходится долго ждать или изящное и простое решение рождается в длительных «муках», а вы сразу удаляю акк.
0
Вы считаете что я не прав — ок. Скажите, как в противном случае защититься от «я зайду раз в месяц, потрындю на тему пару дней, и сгенерю пару строк кода». Ведь это будет 100500%
0
а от этого не надо защищаться. Наоборот — из этого нужно извлекать пользу. Кто-то зашел и неочивидный баг исправил, отправив pullrequest, кто-то новые невырвиглазные иконочки нарисовал. Кто-то может работать только в отпуске. А если они забирают ваше внимание — просто игнорируйте. Найдутся те, у кого будет время отвечать…
+2
Без это никуда, частенько в этих трендецах есть хорошие мысли, просто надо уметь их уловить и понять, хотя и не обязательно. С таким же успехом можно сделать проект закрытым или частично закрытым и допускать к коду только через «собеседование». Если хотите открыть код, будьте готовы с фильтрации, а если будете орать на каждый кусок кода, что это фигня полная так сбегут даже те кто хоть что-то делал. Все пишут по-разному и по стилю и по решению, единственное требование, которое стараются соблюдать — коментирование кода и стиль форматирования языка и еще соглашение о названиях о переменных, все остальное это полет. Насколько он будет красив и продолжителен зависит от команды и настроения.
0
Вот стиль это последнее, что меня волнует. Поверьте, совершенно похер, как называется переменная — packageName или PackageName. Но вот Вам пример из личной практики:

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

2. Разработчик, который переписывал то, что ему было не понтяно. Часто приводя в негодность весь модуль. Часто не обращая внимания на то, что модуль используется в других участках кода. Часто тихо комментируя то, что перестало компилится после его изменений.

3. Разработчик, задачей которого было пофлудить. Часы обсуждения концепции, горы переписки в скайпе. За 3 мес было написано 100 строк кода.

Я не против разговоров. Я не против маленьких, но элегантных решений. И с удалением акков после пары недель я тоже, скорее всего, погорячился. Но — как показывает практика — формировать разработку без единого начала и хоть какой то структурированности — верный способ плодить посты на тему, ими и ограничиваясь
+1
Для этого существует функция координатора, а так, как я выше писал, правила.
0
Судя по комментариям идея заранее обречена на провал реализации в команде.
Это вечные холивары:
.NET/Java MySQL/MSSQL/NoSQL Unity/HTML iOS/Android
По себе знаю что хороший программист хорошо знает один стек технологий, но хотя и умеет работать с другими будет пытаться тащить одеяло на себя, это уже заметно в комментариях (уже чуть ли не меряются). Поэтому первый шаг — создание спеки: что пишем, на чем пишем, итерации, планы и тд. Потом это можно вынести на обсуждение.

Вопросы по теме:
1) Нативные приложения зачем, справится и Web со всем ведь может?
2) Описание проекта общее отсутствует(хотя бы ссылка на прошлый пост нужна здесь)
ПС Не слушайте маньяков и узких специалистов, насоветуют… себе дороже будет.
Берите то, с чем в силе справиться самому.
+1
Это вечные холивары:
Дело не в холиваре или конкретном стеке. Я предложил немного изменить направление движения, вместо еще одного ни с кем не совместимого када я предложил распределенное хранилище. А делать это лучше на том, что для этого лучше приспособлено. При наличии открытого апи доступа к такому хранилищу, делать клиентов можно на чем угодно, любого размера/толщины/функциональности и под любые задачи. Пригодится и просто смотрелка, и просто редактор схем и просто редактор плат, и авторазводчик, и генератор герберов и еще куча всего. И это не обязано быть в одном флаконе и написанное одним автором или коллективом авторов. Что, в итоге, даст возможность пользователю выбрать наиболее удобный набор инструментов под свои задачи.

P.S. главная заморочка тут, это выработать такую модель данных, кто бы редактор плат не мог порушить схему, а редактор схем — плату.
0
Если вдруг каким то образом соберется пул программистов, которые скажут «яве на сервере быть» — так и будет. Пока же, повторюсь, я пишу один, потому делаю на том, что ближе. Кстати, ничего страшного в использовании ASP не вижу, на нем так же построено немало высоконагруженных/ответственных систем и проектов.
0
1. Натив для того, чтобы работать в оффлайне. Не у всех есть возможность работать 24/7 в интернетах.
2. Описание проекта — вещь пока что подвижная. Костяк понятен, мясом обрастает постепенно

что касается не слушать — так и делаю. Между холиварами потихоньку пилю на том, что приведено в топике
0
1. Открою великую тайну: «в броузере» != «онлайн». Делать веб-прилады, способные работать в отсутствии сети, сегодня это уже обычное дело.
2. Какая бы ни была подвижная — должна выгружаться в документ, чтобы у всех было ЕДИНОЕ понимание.
0
Делать веб-прилады, способные работать в отсутствии сети, сегодня это уже обычное дело.
Вот только важно не перестараться, а то получается скайп, жрущий полгига-гиг памяти, тормозящий и плюющийся ошибками JS при выходе.
0
Важно не предугадывать свойства того, что ещё не существует. И очень важно делать больше, чем говорить. Признаком второго подхода является обычно появление сначала демки/прототипа, а уж потом полёт широкое обсуждение.
0
«полёт мысли и широкое обсуждение»
0
Я не люблю веб-приложения там, где можно было бы сделать нативное.
+2
Теперь у меня есть информация о том, что Вы это не любите. Сижу, ломаю голову — как бы её применить? =)) И к чему бы она тут?
+1
Всего лишь при том, что я протестую против варианта «делать как веб-приложение».
+2
Мне кажется, протестовать или поддерживать стоит тем людям, которые вписываются в проект и от выбора его технологии будет зависеть их личное потраченое время-нервы-силы и тд. Если Вы вписываетесь, ну что ж… Тогда это имеет смысл. Если нет — решат сами. Наши пристрастия роли не играют.
+1
Нет, это пожелание потенциального потребителя.
0
Для того, чтобы пожелания потенциальных потребителей имели смысл, их выборка должна быть репрезентативна… И значительна по кол-ву.

А так — послушали троих:
Петя хочет джаву,
Вася хочет web,
А Серёжа только на эрланге с блекджеком и шлюхами…

Кого из троих бум слушать? Да кто ближе по образу мышления разработчику — того и послушает. Вот и весь учёт пожеланий.
+1
в итоге получится очередная неведомая хрень нужная паре разрабов и узкому кругу ограниченных людейевангелистов.
+2
Что Вы предлагаете?
0
предлагаю аффтару не страдать херней, а если не принять участие в опенсорсном проекте, то хоть как минимум запилить плаг решающий одну из мелких лично ему неудобностей.
а если этот плаг еще и будет открытым — вообще замечательно. любой желающий сможет его подпилить под себя.
0
Мне понятна Ваша т.з. Но согласитесь, если бы всегда поступали только так, мы могли бы не увидеть в опенсорсных продуктах никакой альтернативы… Многих хороших проектов не было бы.

Во всём нужен баланс и жизнь сама его прекрасно вносит. Время покажет. Сможет — честь и хвала! Не сможет — будут все пальцем показывать: «Ба, да это же тот чувак, что в первом же топике хлестанулся неслабо и скис!» =)
0
эм. я убежденный сторонник использования проприетарщины. просто потому, что привык к лучшему (опустим вопрос оплаты — моральные угрызения меня не преследуют ночами). просто среди опесорса нет ничего, что было-бы лучше платных приложений.
(или я не нашел. или плохо искал. хз.)
ось — винда (линух на десктопе — не мое)
офис — мелкоофис (либре/опен и рядом не валялся)
разводка — альтиум (всякие поделки тупо не удобны)
фпга — кактус (ну, предпочитаю альтеру. впрочем подозреваю, что и под всякие ксилинксы оно не менее дорогое)
картинки — пейнт (в основном) и фотошоп (сильно изредка) (гимп глубоко в жопе)
вектор — король дров (только не надо про инкскейп, тормозное и валющееся от каждого чиха УГ)
3д — солид, майя (блендер фтопку)
IDE — студия и слик (эклипс еще более-менее съедобен, остальные нах)
компилеры — наиболее оптимальные под проц (кейл, иар, изредка гцц. а под стм8 вообще альтернатив нет)
и т.д. и т.п.
+1
зачем же Вы тогда предлагаете автору принять участие в опенсорсном проекте?
0
отвечу, процитировав тебя:
Сможет — честь и хвала!
лично мне от этого ни холодно, ни жарко. я свой выбор сделал.
но вдруг у человека получится? я за него искренне порадуюсь.
но НЕ ВЕРЮ!(с)
0
Вот с Вами полностью согласен. Пока суть да срач — занимаюсь разработкой в том же ритме
0
Предлагаю советующему не страдать херней и не тратить время на написание комметариев к безнадежному, на его взгляд, делу.
+1
Evangelist — это кто, толсто-тонкий тролль в глазах масс, ну если он не стал конечно к этому времени Icon? :)
0
И ещё… Грех сетовать на холивары, человеку, написавшему два обширных поста о том, что ещё нельзя потрогать. При этом один из двух постов написан достаточно эмоционально с первых же строк и называется «Достало!»

=))
0
Вставлю свои 5 копеек (которые я давно обдумывал на счет всего этого):

1. Делать графическое представление лэйаута и пользовательский интерфейс с его объектами на основе SVG canvas и DOM модели броузера.

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

2. Кодить все на JS.

И клиентскую (front-end) и серверную (back-end) часть приложения. JS уважают и линуксоиды и виндузятники, и гики и реальные пацаны. Ну как бы и некуда деватся от него в такой реализации.

3. Желательно(обязательно) возможность работы с локальным репозиторием (в off-line) проекта pcb, и по необходимости синхронизировать его с сервером (cloude).

4. Желательно(обязательно) возможность групповой разработки проекта pcb на основе одного репозитория проекта в cloude.

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

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

В-принцмпе, есть еще много других идей, и у других есть свои идеи и свое видение всего этого по многим вопросам. Так что обсуждение еще рано заканчивать.
0
1, 2 — обсуждение технологий. Это в предыдущий пост :)

3. — согласен полностью, уже заложено в концепцию.

4. — вопрос сведения исходников. Тут много думать надо, ибо это не сорцы сливать cvn/git. обработка конфликтов разрозненных версий- самая непростая тема.

5. JSON пойдет?

А никто, собственно, обсуждение заканчивать не собирается :))
0
По 1. SVG в броузере — просто из-за экономии времени кодирования (готовая 2D графическая engine уже и готовая объектно-ориентированная и интерактивная) + все удобства браузера (не надо ничего предустанавливать, выход с любого компа с любой ОС) + сама on-line/cloude ориентированная изначальная идеология проекта.

Я анализировал SVG — там все есть, все что надо с точки зрения готовых любых граф.примитивов + готовая интерактивность DOM(навел мышку/щелкнул кнопку на объект в лейауте — через event handling знаем на каких объектах) + разные возможно ненужные плюшки/украшательства.

2. Мне лично по барабану что будет на сервере, хоть черт.

5. JSON естественно, если на JS :)

Только как с языком манипулирования граф.примитивами(язык макросов). Я думал просто JS с перечнем объектов/методов из внутреннего представления лейаута рендеринг энджины клиентской части на JS + набор правил кодирования (что можно/что нельзя) для юзера (это самое простое решение).
0
1. Unity3D. все обработчики + браузер+ натив винды+ натив мака+ в перспективе натив линуха+ мобильные платформы.

5. Примерно так я и предполагал. Учитывая, что нет моделирования схемы, то все достаточно примитивно.
0
По 1. Unity 3D со скриптами на JS или C#? Unity 3D — это хорошо — моден/развивается/быстрая графическая engine + готовая инфраструктура для 3D view.

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

По 5. Т.е. значит — файл лэйаута в формате JSON + вкрапленные в него куски графических скриптов(макросы) на JS:

— Родная для JS сериализация в объекты внутреннего представления
— т.е. нет геморая и тормозов с парсингом, как с xml и прочими форматами
— Быстрый, может быть сжат

Интересно можно ли (что бы не изобретать велосипед) взять за основу готовый формат EAGLE 6, только не в xml, как у них, а перевести его объектное представление в JSON. Нет ли здесь нарушения их копирайта? Так же можно взять за основу текстовый формат KiCAD-а и тоже перевести его в JSON представление.

Можно попытатся составить свой формат, просто как объединение форматов этих 2-х EDA. Можно фичи и других добавить, только у Altium он бинарный (хрен посмотришь) у DipTrace не знаю.
0
Мы уже поняли, что вы фанат JS и облачков — только вот скажите зачем вставки JS в формат данных? чтоб его не смогли обрабатывать другие языки нормально? Или просто потому, что вы знаете этот язык и потому он везде уместен?

Откуда у всех такая нетерпимость к технологиям отличным от своих?

ИМХО — компоненты стоит писать с максимально простыми, открытыми и стандартными форматами, которые понимаются любым технологическими стеками — JSON/BSON один из них

JS — удобен для скриптинга, но не стоит делать его лишь одним возможным языком для этого
+2
Вот старая книжка: Эйрис Р. Проектирование СБИС. Метод кремниевой компиляции (1988) про Кремниевый компилятор, генерирующий 2D графич.файл(лэйаут) для чипов, язык чем-то похожий по синтаксису на Бейсик (но суть не в этом) — не рисовать мышкой, а описывать свой лэйаут на языке. Часто это намного удобнее и особенно удобно при групповой разработке лэйаута.

Предполагается реализовать аналогичное на неком своем объектном API и скриптах на JS. Тем более это API — уже и есть часть рендеринг engine отрисовывающей лэйаут на экране.

Т.е. заместо, например, куска лэйаут файла:
pad 1.0, 0.6, x 1, y 1
pad 1.0, 0.6, x 1, y 2
pad 1.0, 0.6, x 1, y 3
pad 1.0, 0.6, x 1, y 4
pad 1.0, 0.6, x 1, y 5

будет что-то такое:
for (var i=1; i<=5; i++) {
pad(1.0, 0.6, 1, i)
}
0
P.S. Фрагмент
pad 1.0, 0.6, x 1, y 1
pad 1.0, 0.6, x 1, y 2
pad 1.0, 0.6, x 1, y 3
pad 1.0, 0.6, x 1, y 4
pad 1.0, 0.6, x 1, y 5
естественно в JASON виде должен быть.
0
Вы уж извините, но не JASON а JSON и не cloude а cloud — просто очень режет взгляд, когда читаешь
+1
Согласен, самого бесит :-) В тексте без последующ.редактир. часто очепятки, ошибки, косноязычие. Сви топики обычно раз 10-15 перечитываю в течении 1-3 дней — исправляю и переписываю/дописываю кое-что.

P.S. Насчет фрагментов скриптового кода JS в лэйаут файле хотел добавить: технология потенциально опасная в таком самом простом виде :-) Но просто руки чешутся ее применить даже в таком виде — выгоды впечатляют. Здесь надо думать как проще это все сделать — обертка/фильтр поверх JS (т.е. упрощенный и ограниченный диалект JS) или же компилятор на JS в безопасный для приложения JS из другого/своего языка для описания/манипулирования граф.примитивами.

Тьфу, опять косноязычно видимо написал.
0
Думаю, на первом этапе нужно просто вывести на основе JSON из списка примитивов изображение. После этого формат можно дополнить — до первого паблиша он может спокойно видоизменяться/дорабатываться.
0
Естественно JSON!

Быстрая, простая и естественная сериализация/десериализация объектов лейаута со всей иерархией, простая и безграничная расширяемость объектов (просто необходимо подключить новые/обновленные модули объектов в API рендеринг engine), и без тормозов парсинга.

В EAGLE явно лоханулись сделав новый формат на xml :)
0
При том, что я тоже предпочитаю JSON, бывают ситуации, когда XML удобнее (точнее, надежнее).
0
Согласен. Случаи бывают разные, но мне импонирует JSON своей компактностью. XML хорош параметрами.
0
С JSON есть риск наступить на грабли при конверсии типов. Это редко бывает проблемой когда есть контроль над источником и приемником данных, а сама структура данных жестко фиксирована. Тут же на входе могут оказаться данные со структурой разных версий, с ошибками и прочими граблями. В такой ситуации хмл надежнее. А для того, что бы минимизировать оверхед, имеет смысл максимум запихивать в атрибуты, а не вложенные теги.
0
Т.е. это одновременно может присутствовать в лэйат файле — объекты в виде JSON и фрагменты скриптов(макросов) на JS.
0
Юнити совершенно параллелльно. Посмотрите Character controller — там JS соседствует с C# файлами. Единственное правило — в рамках одного файла свитч по языкам не допускается

JSON полностью описывает все то, что было написано ниже относительно формирования. Формат на текущий момент просто взял как выжимку из того, что видел
0
SVG canvas
Не, не надо SVG. Сколько-нибудь сложный SVG, в тех реализациях, которые я видел, хавает просто немерянные объемы памяти.
0
Мифический пост. Что разрабатываете, какая концепция — неизвестно. Хоть бы ссылка была на предыдущий пост. Ну или скопипастить оттуда сюда. А так это все — ни о чем. При этом прошлое обсуждение имело неплохие предложения, которые тут не отражены.
0
То-то и оно, что неплохие предложения потонули в потоке «писать на этом! нет, на этом!».
+1
религия запрещает собрать выжимку?
0
Незаконченность обсуждения не позволяет. Имеете что то против финализации обсуждения?
0
там она не достижима в принципе. ;)
но вот краткий список полезных (с вашей тз) идей был-бы очень полезен. как минимум в качестве напоминалки.
0
По итогам — соберу в единый документ.
0
В общем срач переехал сюда.
Каждый тянет в свою сторону — жаба, мускуль, касандра, asp, js, uniti, svg…
Хоть кто-то подумал о том как всё это будет деплоиться у клиента?
Кто-нибудь подумал о том, сколько такой неповоротливы стек потребляет ресурсов?
Тут все считают, что клиент будет сам ставить стек из серверов, бд и прочего, который будет просто на фоне крутиться всё время? Или что хапуск приложения будет состоять из 20 стадий (базу, сервер, обновления, UI)?
Как вы всю эту байду собираетесь синхронизировать потом?
Проект задумывался как решение существующих проблем, а не создания новых — а всё что пока есть, это таскание одеяла на себя с попытками доказать чей стек лучше для выполнения…

Как было сказано уже KISS — меньше не нужных компонентов, которые лишь потому что круто или потому что это же мой любимый стек для решения других задач.
Стандартные форматы где только можно, меньше зависимостей от специфических компонентов, и без избыточности ненужной (вроде XML)
+1
Чёта я так и не понял, что собственно разрабатывать то собираетесь? *чешет затылок*
-1
Чёта я так и не понял, что собственно разрабатывать то собираетесь?

EDA PCB рисовалку для open source hardware и не только:

1. с возможностью работать из броузера в off- и on-line режиме

2. с базой на сервере (cloude):
a) компонентов:
— фут-принт
— УГО(Условное Графическое Обозначение под любой стандарт(ЕСКД/ IEC 60617/IEEE Std 315))
— datasheat
— прочая инфа
— Wiki
б) готовых лейаутов
в) репозитариев для групповой и одиночной разработки PCB

3. open source ядро клиентcкой части/сервера
с возможностью подключения самописных mod-ов/плагинов/скинов/скриптов и т.п.

4. Вроде бы ничего основного не забыл?
0
Это было понятно изначально, что так и будет. Потому что нет четко поставленной цели и задачи, а есть только описание «хотелки», хотя не понятно, что же автор хочет получить, т.к. в старовом посте, на текущий момент времени, нет никакого описания проекта. Есть только
а) понять, чего не хватает в готовых решениях
При этом ни слова о том, что же все-таки разрабатывается. В итоге появляются описания проекта в куче комментариев, причем каждый пытается объяснить своими словами, но это все не то. Нужно описать задачу в заголовке темы.
Вот и получаем, что народ начинает предполагать, гадать, предлагать то, с чем он сталкивался, не имея представления о будущем проекте.
0
Срач перешел в несколько иное русло, на мой взгляд более конструктивное. Ну, за исключением отдельных непонятливых с позицией «вы хуйня на палке и я не пожалею времени, чтобы об этом сообщить».

Никто уже никуда не тянет. Технологии клиента/сервера определены на текущий момент.
Деплой у клиента посредством приложения-деплоера. Для мобильных платформ — через сторы. Формирование репозитория клиента — на основании файлов проекта, использовать БД смысла не вижу — уже не раз сталкивался, что из за настроек безопасности разворачивается некорректно.
Если говорить о ресурсах клиентского приложения — то планирую минимальные около 2 ядер и 2 Гб ОЗУ. Что касается сервера — волнует мало — 4 т.р. за 8 ядер и 32 Гб ОЗУ — не деньги.
Синхронизация посредством запроса контрольной суммы и получения через транспортный уровень списка обновлений установленных компонентов. Но, ИМХО, вопрос был связан с преположением, что все это добро развернет херову тучу БД и сервисов.

Никто одеяло не таскает. Пока это все на этапе «а лучше писать на этом» — рассматриваю не более чем флуд и продолжаю делать на том, на чем решил. Если появятся какие то конкретные предложения — тогда и будем думать. В конце концов, стараюсь выносить всю логику на абстракный уровень, алгоритмы которого потом портируются несложно. Как подтверждение — поменяв даб-пи-эф на юньку, я тупо перекидываю файлы моделей данных, их загрузки и прочего, просто контролируя компилирование исходников. Так что болльшая часть работы сохранена
0
Если говорить о ресурсах клиентского приложения — то планирую минимальные около 2 ядер и 2 Гб ОЗУ.
«Системные требования современных игр больше напоминают системные вымогательства».
+2
Блин, Вы хотите все и сразу. И чтоб красиво и современно, и чтобы на 486 шло. Так не бывает :)
-1
не забудьте еще DX9-10-11 видушку в требования заложить. ;)
0
Если не требуется ренеринг херовой тучи мешей, то с графикой справится и IntelGraphics на самой чахлой матери. И да, Вы-ж вроде уже высказали свое отношение к затее — что мешает остановиться в раскидывании язвительного контента?
0
ну скажем альтиум хочет DX9 видушку. правда в основном она нужна при показе 3D вида платы.
0
DX9 видушку и винда хочет, так что все путем.
0
ну в общем да.
с другой стороны альтиум начал хотеть видушку раньше чем винда.
0
У разных платформ — разные задачи, согласитесь. Это все равно, что «А-я-яй, STM32 с хардверным USB стоит так дорого, вот бы его да в тиньку 2313»
0
А Вы не огорчайтесь «за таких людей», их есть много у нас, просто щас только начало/многим не понятно и «вот люди у нас просто ТАКИЕ», что не помешает им, возможно, вполне вменяемо учавствовать в разработке :)
0
Там я думаю спокойно хватит 1GHz + 1Gbyte, поскольку графика 2D — представьте, что это не крутой стрелялка-блокбастер 3D типа HL2, а 2D аркада или инди-игра :)
0
+1
0
А чего +1-то? «Два ядра, два гига, посредине мамка» — твоя версия требований. Я тоже склоняюсь к тому, что для таких требований нужно очень криво писать. Или на чем-то вроде JS, который со сносной скоростью только в хроме пашет. Ну разве что выжрать два гига на действительно сложной схеме — это еще допустимо.
0
Есть минимальные системные требования, а есть — комфортные. Вот для комфортной работы я и описываю. А так — да, думаю оно и на гиге того и того (частоты и ОЗУ) работать будет.
0
Ну комп 2/2/2 core/Ghz/ram/ — вроде бы как 2 года уже самый минимум. Android-ы уже c прошлого года пошли 2/4 core 1GHz 1/2G ram
0
Лично у меня компу уже лет под шесть. Хотя довольно близко — C2D E6300 (2@1.86GHz), 3GB RAM. Оперативки не хватает, но с WinXP x32 выбора нет. Ведропланшету года нет, а он уже устарел — на A10.
0
Просто как сейчас работают:
Броузер открыт с 10/20 вкладками + Eagle + Altium + WinAMP + еще куча чего. Лет 6 назад так не делали.
0
Я примерно так работал еще лет 15 назад, под полуосью. Попытка работать в таком стиле под виндой тогда приводила винду к состоянию очень неспешного слайдшоу.
0
ИМХО, проблема планки оперативы яйца выеденного не стоит. Браузер с 15-20 вкладками, 4-5 экземпляров студии, MSSQL MS, Expression, Skype, ну и виндовые плагины — даже с зубодробильными проектами не видел загрузки более 8 Гб. При цене пары планок на 8 Гб в 2 т.р. не вижу никакого смысла экономить.
0
WinXP в принципе не видит более 3.25GB (3.5GB по другим источникам). И 15-20 вкладок — это фигня. Skype, Steam и, особенно, NV TurboCache раздражают своими аппетитами.
0
Вы вероятно имеете в виду 32х битную версию, тогда да — 3 × 1024^3 байт
но 64 битная версия такой проблемы не имеет…
0
Разумеется 32-битную. x64 на то и x64, чтобы не иметь подобных ограничений.
0
*** — напомнило старинный советский мультик ))

— Марио идет грабить банк!…
— Отдам, когда ограблю банк…
— Потомок князей Бриндизи никогда не запятнает своих рук работой…
0
  • avatar
  • valio
  • 01 февраля 2013, 10:55
Два вопроса: «Чем» и «Зачем». Чем не устраивают текущие open-source рисовалки(например тот же KiCAD или gEDA PCB), и зачем городить ещё один велосипед, не проще ли взять готовый и допилить его до своих нужд? Разработать тот-же сервис хранения компонентов(хотя чё там за сервис, для этого обычного ftp сервера хватит :) и добавить в KiCAD возможность их получения оттуда(обновлять). Тоже самое с плагинами. Потому как колхозить своё, не факт ещё что получится, и не известно, на сколько всё это затянется.
+1
Объясню свою позицию. Во первых — мне интересно создать решение, получить новые скиллы, и избавиться от того, что не устраивает. Что конкретно? Кривая работа с блоками, кривое (во многих системах) добавление компонентов, отсутствие базы компонентов, подхватываемой на лету, отсутствие списка готовых схем (часто бывает так, что даже схему из даташита сидишь, и как последний мудак перерисовываешь, тратя на это свое время и силы). Одним словом — при существующем развитии технологий можно написать качественно новое решение, избавленное от недостатков предыдущих систем.

По поводу сервиса компонентов — ftp в данном случае — самое простое, но и самое ненадежное решение. Тут же возникают вопросы — как будет происходить добавление компонент пользователями, как будет синхронизироваться набор библиотек, как будет происходить выборка среди набора обязательных/подгружаемых компонентов (представляете себе скорость работы системы, у которой в директории 80к+ файлов, описывающих один компонент?)

Что касается не факт что получится и неизвестно насколько затянется — тут Вы совершенно правы. Гарантий никаких. Кроме тех, что в случае «да ну нах» я буду уже не просто пиздоблом, договорившимся со своей совестью, но пиздоболом, который обосрался перед целым сообществом. Согласитесь, несколько разные уровни ответственности.
0
Ну так давай разрабатывай.
А то «пиздеть» не мешки ворочать. Я тоже многого могу наобещать…
-1
Два унылых топика, о таких же унылых и ограниченных размышлениях… да что же это?
0
FTP это для примера. Самое главное в твоей задумке это сервис компонентов(pcb рисовалка уже не главное), и по сути всё остальное крутится вокруг него, вот отсюда и начни. Сервис должен:
1) Иметь понятный и удобный формат компонентов(скажем на основе JSON, или что лучше взять готовый, скажем от KiCAD). При этом максимально унифицированным с форматом других CAD пакетов(по возможности, хотя не обязательно).
2) Хранение уже созданных компонентов, с возможностью их поиска(по названию, параметрам, возможно, схемам применения).
3) Позволять добавить новые компоненты пользователям.
4) Иметь встроенный граф. редактор для рисования компонентов(тоже не обязательный пункт, если в качестве основного формата компонентов будет принят формат одной из существующих CAD, скажем того же KiCAD, тогда пользователи смогут просто рисовать его в KiCAD и нажатием кнопочки на панели инструментов отправлять его на сервис, и таким же нажатием кнопочки, загружать его оттуда).
5) Также сервис должен хранить соответствующую компоненту инфу(параметры, схемы его использования из ДШ, возможно, footprint).

Неплохо бы ещё продумать «трудности», главная из которых — Кто всё «это» будет заполнять? (при условии что сервис уже существует и исправно функционирует)
Начини с формата компонентов и формата их хранения, а также храниня их метаинфорации. Сама концепция репозитария компонентов для CAD, думаю будет вполне востребована(по аналогии репозитария пакетов в Linux дисрибутивах)
0
Был один такой «программист», — Денис Попов ))
lurkmore.to/%D0%94%D0%B5%D0%BD%D0%B8%D1%81_%D0%9F%D0%BE%D0%BF%D0%BE%D0%B2
Ну так DtcDev по намерениям очень на него похож :)
-1
Ну а почему бы и нет, пусть человек пробует, глядишь состряпает чего путнее. Правда по описанию автора, кажется что пыла-жара много, а конкретные технические решения будут потом рождаться в муках.
«разработка клиента на Unity3D, портирование под мобильные платформы.»
Это в этой задаче явно лишнее, пользоваться CAD на «пальцетакалках» не очень удобно.

Если автор так уж решил делать эту разработку, то я бы предложил ему разбить её проектирование на несколько этапов, и по каждому этапу отписываться здесь(что сделано, что планируется, какие варианты решения приняты по той или иной задаче), чтобы народ мог обсудить, поправить если что, подкинуть идей. Всё проще будет. Да и ошибок меньше.
0
Я думаю все окажется значительно проще.
После первой же попытки «Творить», Автор забьет на свои амбиции, и все затихнет ))
0
По поводу мобильных платформ — если есть возможность работы на юнити, а, главное, ее функционала хватает для реализации — почему бы не заложиться?

Что касается этапов — для начала разберусь с отрисовкой компонентов, после чего — обращусь с описанием редактора схем. Основной вопрос на текущий момент — генерация графических примитивов на основании самих векторов. В юньке, по поверхностному изучению (сейчас занят переносом моделей данных из WPF), существует две возможности — полноценная 3D линия и вывод простых примитивов через пространство дебага. Нужно попробовать оба варианта. после чего и решать.
0
В процессе я бы еще посоветовал постараться сформировать свои требования к формату хранения данных (я бы даже сказал к доменной модели и формату сохранения данных в ней), потом посмотреть существующие форматы и либо перейти на какой-либо существующий, либо усовершенствовать свой. Собственно, грамотный, продуманный и разумно расширяемый формат хранения это ключевой элемент того, что вы задумали.
0
спасибо. В основу положил формат хранения данных Eagle, немного его дополнив для удобства работы с оглядкой на платформу.
0
Форматы хранения данных разработаны. Написана логика для сериализации/десериализации.

Написан парсер для двух популярных форматов (не знаю, насколько корректно их называть). Единственное, что не решил — как обрабатывать конфликты, когда данные одного источника не соответствуют уже хранящимся в БД — пока что «кто последний высказался, тот и прав». Сомневаюсь, что то будет проблемой с общедоступными компонентами, которые выверены веками, но вот с создаваемыми самими пользователями, которые по сути не проверяются — вопрос. Как временное решение — попросту не обрабатывать файлы с сомнительным источником, либо выставлять им флаг «не подтвержден».
0
Как временное решение — попросту не обрабатывать файлы с сомнительным источником, либо выставлять им флаг «не подтвержден».
Возможно имеет смысл делать не бинарный флаг подтвержден-не подвержден, а что-то типа confidence level. Чем он выше, тем надежнее (провереннее) данные.

P.S. иногда весьма не хватает наличия в компонентах версий футпринтов. не просто под разные корпуса, а именно версий одного и того же, скажем, один вариант под рифлов, один под ручную пайку, один под пайку волной. и, естественно, что бы программа учитывала, где разные футпринты, а где версии одного и того же.
+1
Ок, спасибо за замечание, учту.

По итогам обсуждения выложу финальный вариант форматов данных на обсуждение.
0
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.