Комментарии 77
Теперь туда же юнит тесты. Типа на точке а 5в, на точке б 0, тогда на точке в должно быть от 2.5 до 2.7.
Для человека, который вообще никогда не занимался железом (то есть меня): как так получилось, что файлы в проектах не хранятся в текстовом формате, который хорошо залезет в git? Ведь на скриншотах какие-то схемки.
Я знаю что KiCad генерирует текстовые файлы, но давайте представим как вы будете глазами сравнивать дифф этих файлов. Формат SVG тоже текстовый, но вряд ли кто-то сможет легко сможет сравнить две картинки смотря на текстовые исходники.
Собственно, по изменению исходных кодов программист тоже не всегда может сравнить две версии приложения — скорее направление, куда смотреть.
Например с помощью KiCad-Diff
git diff можно настроить, чтобы использовать сторонние утилиты для сравнения файлов. см документацию
сложно в это поверить. Единственная разница — бинарные файлы пишутся/читаются быстрее.
А так любой уважающий себя софт имеет 2 версии файла — текстовую для системы контроля версий/ручных фиксов и бинарную для всего остального. Могу рекомендовать ознакомится с Autodesk(Alias/Wavefront) Maya — 25 лет у них все получается;)
Я раньше был инженером-конструктором, могу привести пример из своей области.
Деталь — это не набор точек, а последовтельность операций над деталью, примерно как гит. Все размеры динамические. При изменении одного размера перестраивается все дерево, все зависимые от него элементы, сотни и тысячи точек на результирущей моделе. Плюс там же идет чертеж этой детали, которые тоже пересчитывается. При изменении одного параметра дифф в текстовом виде будет на тысячи строк, т.е. полезность его стремится к нулю.
По поводу хранения этого в текстовом виде -одна деталь это по сути как микросервис, с десятками файлов, с гитом, каждая деталь станет отдельной папкой,-даже в маленьком проекте из 100 деталей это будет выглядеть как будто вы скачали 100 микросервсиов и пытаетесь с ними работать.
Плюс не представлю как это будет объем если хранить это в текстовом виде, а также скорость работы-все-таки парсить текст несколько дороже, а производительность для кадов до сих пор очень больной вопрос.
А когда модель(деталь) закончена — она запекается(baking) — т.е. удаляется вся история и всё переводится в абсолютные значения (вам по САПР дожно быть тоже это знакомо — когда всё экспортится в тот же STL для последующего производства).
И вот этот результат лучше хранить в бинарном формате и передавать дальше по pipeline(на станки или в рендеринг/компоузинг). И да, после запечки, разумеется, будут те самые сотни тысяч точек на результирующей модели — но это уже финальная стадия.
upd: я не утверждаю, что все САПРы такую архитектуру имеют — тот же ранний AutoCAD for DOS — точно нет.
Текст очень неплохо сживается даже дохлым древним ZIP, а специальные форматы типа PPMd и того сильнее. Когда OpenOffice стал свои документы хранить в формате XML-ZIP, это смотрелось дикой ересью. Особенно выбор XML — это текстовый формат с дикой избыточностью. А сейчас даже Microsoft Office выкинул свои бинарные форматы и стал делать так же.
Заодно, кстати, сравните размеры одного и того же документа в виде файлов .DOC и .DOCX или .XLS и .XLSX
> также скорость работы-все-таки парсить текст несколько дороже
Скорость обычного жесткого диска на несколько порядков ниже скорости процессора. А сжатие текста, во всяком случае в случае MS Office, приводит к многократному уменьшению размера файла.
Т.е. в предположении, что файл данных читается/пишется целиком — мы получаем ускорение относительно большого бинарного файла. Медленный процесс — чтение с диска — ускоряется. А что во время чтения процессор занят больше обычного на распаковку и парсинг — так он всё равно бы простаивал зря.
Бесплатный бонус — защита от случайных повреждений. Если в бинарном файле поменять пару байт (сглючил диск, или память, или сеть при копировании), то обычная программа этого не заметит и будет работать с испорченными данными. А zip просто не распакуется и повреждённость данных будет замечена при первом же чтении.
Вот если файл данных многократно превосходит доступную память и его надо читать-писать по частям, типа видеофильмов или огромных баз данных — вот тогда такой трюк не сработает и надо будет делать бинарники. Хотя бы в виде папки с множеством отдельных текстовых файлов :-)
> Деталь — это не набор точек, а последовтельность операций над деталью
> При изменении одного размера перестраивается все дерево
«Кто нам мешает — тот нам и поможет».
При просмотре разницы — просматривайте только разницу в истории операций и игнорируйте (вручную или программно) разницу в тех самых вычисленных точках.
Кстати, необходимо ли в исходном проекте хранить те самые вычисленные точки — это само по себе вопрос. Обычно же есть исходные материалы, и есть результат работы. Какой-нибудь «Аватар» — есть описание компьютерных сцен, а есть РЕЗУЛЬТАТ многочасового рендеринга, который мы смотрим в кинотеатрах. Первое для создателей сохранять надо обязательно, а вот второе — нет, второе уже отгружается потребителям, когда все изменения закончены.
Текст очень неплохо сживается даже дохлым древним ZIP, а специальные форматы типа PPMd и того сильнее.
Скорость обычного жесткого диска на несколько порядков ниже скорости процессора. А сжатие текста, во всяком случае в случае MS Office, приводит к многократному уменьшению размера файла.
В начале ветки же разговор идет о хранении в текстовом виде для того чтобы обычный гит показывал диф. Поэтому в данном контексте зип == бинарный формат.
При просмотре разницы — просматривайте только разницу в истории операций и игнорируйте (вручную или программно) разницу в тех самых вычисленных точках.
В моем представлении смотреть в каде все равно значительно проще. Соменваюсь что можно представить деталь видя изменения координат 20 точек и нескольких парметрах в операциях например гибки. Нередко бывало на сложных деталях я мог увидеть подходит ли изменение какого-то параметра только изменив и увидев как поедут все размеры на детале.
Кстати, необходимо ли в исходном проекте хранить те самые вычисленные точки — это само по себе вопрос. Обычно же есть исходные материалы, и есть результат работы. Какой-нибудь «Аватар» — есть описание компьютерных сцен, а есть РЕЗУЛЬТАТ многочасового рендеринга, который мы смотрим в кинотеатрах. Первое для создателей сохранять надо обязательно, а вот второе — нет, второе уже отгружается потребителям, когда все изменения закончены.
Ну по такой логике и гит концептуально неправильно работает-он хранит конечное состояние.
Но если засунуть — то будет хранить, неэффективно и возможно с частичным разрушением (настройки EOL Windows/Linux/MacOS)
> он хранит конечное состояние
Конечное состояние — это EXE ( elf, etc), которые запускается у пользователя.
А может быть даже не EXE, а установочный пакет (ISO, MSI, APK, ....)
Такое в Git'e не хранят, если на трезвую голову.
> чтобы обычный гит показывал диф. Поэтому в данном контексте зип == бинарный формат.
Если ради diff — то да, нужен текстовый формат.
Причём не просто текстовый, а разбитый на короткие строки (однострочный «лаконичный» xml или json тут хотя и текстовый формально, но всё равно не пойдёт).
Насколько понимаю, для этого придуманы git filters: плагины, которые разбирают файлы на набор удобных для diff'a текстовиков.
И думается мне, сделать в качестве входящего фильтра unzip плюс переработку xml (каждый тэг с новой строки) проще и надёжнее, чем «вскрывать» чей-то бинарный формат, с частичной (или отсутствующей) документацией, и в добавок который при обновлениях программы тоже может дополняться/изменяться.
Качественно — и так и так не очень удобно, и так и так в принципе возможно.
Количественно — варианты типа xml-zip проще и надёжнее.
> только изменив и увидев как поедут все размеры на детале
Но бывает и обратная задача. Когда нужно быстро сравнить «конкретную цифру». Например, у вас вдруг разъехалась схема, с которой вы много месяцев не работали, а тут вдруг «стряхнули пыль» — и нате. Вы определили, какая именно «строчка» файла породила эти изменения. Теперь, чтобы вам понять в какую сторону плыть, вам нужно быстро определить, кто когда и с какой целью эту строчку изменил. И вот тут легковесный просмотр diff'a в блокноте, занимающий долю секунды, гораздо удобнее любого многофункционального красивого просмотрщика, который будет загружаться секунд 5-10. А построчная аннотация (git blame) и того лучше.
В индустрии компьютерной графики(CG) к комбинации бинарного(для скорости, что было особенно акутуально для HDD/ранних сетей) и текстового(для системы контроля версий/парсинга) пришли давно (можно даже сказать, что всегда использовали эту комбинацию) — но там было намного более плотное взаимодействие пользователей и разработчиков. Например, Pixar — те же люди, что писали RenderMan — стали делать и мультики. Или использование Maya (как и её предшественника PowerAnimator) в сколько-нибудь сложных проектах в сравнении с 3DStudio Max в т.ч. обьясняется и возможностью сохранения в ASCII.
Надо открывать обе версии паралелльно друг другу и сравнивать глазами ПП, а не их исходный текст.
И да, «мерджить» придётся вручную, потому что где-то перенесли track, где-то подправили маску, и после этого перезалили полигоны. И всё.
EDIT: Даже текстовый файл настроек проекта *.PrjPcb никто не будет сравнивать вручную, уж слишком много полей. Хотя, редактировать иногда приходится, когда тот или иной баг Алтиума не позволяет сделать то, что требуется.
zhovner простите за оффтоп: когда можно ожидать первые флипперы? Судя по отсутствию обзоров и распаковок в ютубе первая партия еще не дошла до адресатов?
одновременное редактирование все там же невозможно
Как вы представляете себе одновременное редактирование, например в Фотошопе? Да, мы все привыкли Googe Docs, но почему тогда с кодом мы так делаем? В общем я пока не представляю как можно было бы сделать одновременное редактирование одного файла в Altium.
Правда я себе с трудом представляю, как такое выглядит не на демонстрациях, а в реальной разработке. Но раз такой функционал есть, значит он востребован. Иначе бы его не запилили.
Вообще с кодом тоже делаем, просто за это приходится расплачиваться конфликтами позже.
а вот например, как это реализовано в Pads:
www.youtube.com/watch?v=eH59LUc9thk&t=91s
В качестве альтернативы отмечу, что у Альтиума с некоторых пор есть какая-никакая интеграция с git'ом — например, диффы таки можно посмотреть:
Но насколько я понимаю, мерджи делать будет почти невозможно, поэтому на мой взгляд вместо гита лучше подойдет (о боги!) SVN, поскольку в нем можно делать глобальный лок на редактирование.
Пока только между релизами, посмотрите видео (таймкод) https://youtu.be/FeSoRvQZSNQ?t=588
Скоро обещают графический дифф между коммитами. Уже есть в бете, но мы пока не пробовали.
В Лондоне они наняли юридическую контору которая специализируется на ловле пиратов и нелегальных пользователей.
Работают очень эффективно, в самой программе встроены некие механизмы удаленного отслеживания.
Поэтому малейший отход от лицензии вызывает письма из Лондона.
Лицензию надо продлевать каждый год.
В этой связи вопрос: останется ли доступ к облакам, когда истечет срок годовой лицензии на сам Altium?
В этой связи вопрос: останется ли доступ к облакам, когда истечет срок годовой лицензии на сам Altium?
Да, доступ останется read only.
В целом, вся ваша деятельность выглядит как пример смузи-стартапа, которому очень повезло в плане денег и можно работать в удовольствие, совсем не заботясь о сроках и о коммерческой составляющей проекта
Недавний пост в блоге Altium про это — resources.altium.com/p/state-electronics-industry-2021?utm_source=altium-designer-app&%3Butm_medium=referral&%3Butm_campaign=my-altium&%3Butm_content=article
В этом плане была бы очень полезна статья про ActiveBOM и как одним кликом в Altium проверить все компоненты на наличие в стоках и прогнозы на их наличие.
Типа — на работе кайфуют? ух гааадыы…
А как должно и могло бы быть для абсолютно нишевого и нового продукта, на ваш взгляд? Ну, типа, как «правильно»?
Я просто вспоминаю как на новую Элиту бейкерствовал — так я игру даже и не ждал к примеру. Просто считай оплатил часы удовольствия из детства. А через пару лет приезжает почта — вот бета, вот ключ, лети.
Я если что, не бейкер флиппера. Но представить бейкерство в их пользу просто что бы люди так кайфующие от того что делают, продолжили этим заниматься — без проблем.
Плюс я узнал, что существуют системы для разработки железа и как они решают совершенно неочевидные со стороны проблемы. И это лично мне уже может пригодиться.
Работа над Flipper Zero — это процесс ради продукта. Каждый наш бэкер, вложившийся в наш проект, получит свой Флиппер, в этом и задумка. В этом и заключается вся суть краудфандинга.
Предзаказы мы запустили только по одной причине: тысячи опоздавших очень просили хотя бы какую-то возможность вписаться в затею.
Именно из-за нежелания выглядеть как машина по сбору денег мы отказались от идеи брать полную стоимость устройства на стадии предзаказа. Просим $10, потому что не просить ничего нельзя: нужно хоть немного минимизировать процент отказавшихся, ведь нам нужны более-менее точные планы на производство. Взамен, как и на Кикстартере, предлагаем значительную скидку.
Если кому-то не нравится платить без моментальной отдачи, можно дождаться выхода Флиппера в розничную продажу и купить по полной цене живое устройство, которое сразу отправится в доставку. Это примерно осень 2021.
можно работать в удовольствие, совсем не заботясь о сроках и о коммерческой составляющей проектаЭто называется «делать продукт как положено, а не как быстрее и дешевле». Всем бы так работать!
Граничные параметры должны быть в любом случаеБесспорно, definition of done — must have. Я бы даже сказал, с этого следует начинать )
Но определившись с требованиями и критериями, не следует гнаться за «time to market».
И экономить на всём подряд тоже не нужно.
Именно этот смысл я вложил во фразу «делать продукт как положено, а не как быстрее и дешевле».
Или есть возможность поднять все локально на своих серверах?
Для настоящей командной работы в локалке у Altium есть NEXUS.
Но там цены похоже еще выше если даже команда Flipper его себе не может позволить.
Для работы в локальной сети организации на данный момент есть 2 продукта:
1 — Altium ConcordPro — в котором реализованы основные возможности платформы по работе с библиотеками компонентов, проектами, web review, project history и тд more details https://www.altium.com/concord
2 — Altium NEXUS — решение для команд с формализованными процессами, по факту вся функциолнальность ConcordPro + управление процессами more details https://www.altium.com/altium-nexus
а без дополнительных параметров сколько?
Ну может в будущем я начну коммерческое её использование, когда прокачаю свой навык достаточно хорошо.
Ок. Предположим в СМП состоит компания. Микробизнес Сколько? Вот не понимаю я, почему так не любят крупные "серьезные" компании выставлять прайс. Хотя бы с пометкой *цены могут измениться в зависимости от...
Помимо всего связанного с Altium, понравилось наличие на hardware проекте тестировщика. Первый раз встречаю такое среди железячных компаний в статьях на Хабре. Наконец-то!
«очень легко» — это перебор.
Просто папки с законченными (выпущенными, зафиксированными, переданными в другой отдел, опубликованными, etc) версиями надо закрывать на запись. Хочешь поправить — делаешь копию и правишь в ней. Случайно поправить по месту не даст Windows/Linux.
Но это требует внимательной ручной работы: закрыть на запись можно просто забыть, ведь решение о фиксации версии обычно принимается несколькими людьми в течение нескольких дней, а не в одну секунду в одном месте. Опять же, можно письма «бегунки» делать, а закрыли ли вы папку у себя на диске, или ещё как. Но в общем, в текучке забыть и не сделать, в самом деле, вполне реально. Тем не менее, «очень легко» — это перебор.
Еще одна возможная проблема с подходом «много папок» — это многократный расход дискового пространства. Что может быть оправдано, если часто нужно именно заглядывать в «исторические» версии, например искать появление и эволюцию конкретной детали (файла, блоки информации в файле, etc).
Опять же, частично и вручную сглаживается сбросом старых версий в архив, или на сервер файлопомойку с дедупликацией.
С автоматизацией безусловно удобнее, но «ну ужас, да, но не ужас-ужас-ужас».
Кстати, про автоматизацию не сказали одну ключевую вещь: а именно гарантии того, что на компьютерах F.D. всегда есть минимум две полных копии всех файлов. Что если завтра Altium 365 по любой возможной и невозможной причине станет недоступен — работа не прервётся и всё файлы по прежнему будут доступны работникам, пусть и с меньшими удобствами.
В идеале, должна быть возможность разворчивания локальной службы Altium 365, «on premises». В этом, кстати, хорош Git/Mercurial/Bz2/Veracity: для них любая сетевая папка — уже полноценный репозиторий, и хранение своих исходники на битбакетах и гитхабах никак не противоречит одновременном хранению их же на файловых серверах компании.
Я-то думал, наконец-то замутили подписку ))
А это всего лишь репозиторий. С этим вполне справляется SVN и Git. Причем, без привязки к альтиуму, что довольно актуально при нынешних отношениях компаний из недружественных стран с российскими пользователями. (Shut up and take my money!)
К тому же, у нас множество проектов сделано в КиКАДе и продолжает делаться.
Вместо веб-интерфейса просто кладем в отдельную папочку pdf версии документов, а в другую - технологические файлы для производства. Нормальные инструменты типа Araxis Merge вполне могут сделать дифф двух схем в pdf и не только схем.
Для разграничения доступа есть lock.
В общем, у альтиума опять получилась в меру удобная свистоперделка типа того же драфтсмана. И наверняка с кучей ограничений, как обычно
Altium 365 — как GitHub, но для разработки железа. Как мы делаем Flipper Zero