Статья должна называться так: "Минцифры поддержало введение запрета на удалённую работу в IT-компаниях для сотрудников, находящихся за границей, работающих над госпроектами"
Мне приходилось экспериментировать с распаковкой бинарных файлов MATLAB, но не очень удачно.
Чтобы поменять код в live-скрипте, мы распаковывали mlx, меняли код во внутреннем m-файле и запаковывали назад в mlx. И по началу оно работало хорошо, но потом начали ловить странные баги в обработанных скриптах. Пришли к выводу, что ручная перепаковка работает ненадежно и лучше ее избегать.
Кстати, не так давно в матлабе появился способ теснее интегрироваться с Git/SVN. Суть в том, что матлаб регистрируется в системе как инструмент для проведения сравнений и слияний:
В таком случае после git diff или git merge автоматически открывается MATLAB/Simulink. Если пользовать гитом из командной строки, то так наверно чуть удобнее.
Еще мне пришлось провести работу над собой и убедить себя, что коммитить бинарные mlx-скрипты не так уж и страшно, если они реально полезны для решения задачи :) Тем более если кодовую базу максимально выносить в m-файлы и собственные библиотеки.
По моему опыту, если вы действительно рассматриваете матлаб для работы, вам не только продлят триал больше чем на месяц, но и помогут разобраться, чтобы быстрее принять решение.
На самом деле все усложниться еще больше. Git действительно надо изучать, в том числе методом проб и ошибок. Я статью специально упростил, чтобы снизить порог входа для новичков. Ну и показать, что даже в своих небольших локальных проектах гит полезен.
Важно понимать, что контроль версий - это краеугольный инструмент для разработки. Вести без него даже средний проект на несколько человек это просто самоубийство. То есть можно конечно (что я вижу часто в инженерке), но это приводит к таким проблемам, что лучше весь отдел обучить гиту, чем потерять проект на полпути из-за того что на показательные испытания попала кривая прошивка непонятно кем, когда и из какого кода собранная, в результате устройство сломалось, а что чинить, не понятно (такое тоже видел).
Резервное копирование данных - еще один очень важный инструмент, но контроль версий он конечно не заменяет.
Согласен, тем кто работает на военку противопоказано в принципе заливать свой код в интернет. Лучше использовать локальный GitLab.
К слову я о портале GitHub для хранения кода в статье ничего не писал. Наверно надо пояснить в тексте, что приложение GitHub Desktop никуда само код не отправляет.
Понимаю, о чем вы. В этой статье хотелось не научить полноценно работать с гитом (тут одной статьей не обойдешься), а объяснить инженерам, что гит им необходим, и помочь войти в тему. А дальше обязательно нужно рассказать про ветки и удаленные репозитории.
За рекомендацию Sourcetree спасибо, посмотрю, что там. А работать с гитом только из матлаба мне лично очень больно, не хотелось отпугивать новичков бесконечными контекстными меню :)
Я сам с гитом 95% времени работаю из приложения GitHub Desktop. Из матлаба разве что проверяю изменения в моделях и приложениях App Designer - тут других вариантов нет.
Вообще, как я понял, сейчас модно встраивать интеграцию с Git во все среды разработки :)
Когда модели симулинк были текстовыми файлами, было поприятнее)
Впрочем, и сейчас в качестве бинарников они весят мало, так что даже старые репозитории с большой историей не отъедают больше нескольких ГБ. А отслеживать изменения через интерфейс Simulink в принципе достаточно удобно, хоть и требует пары лишних телодвижений :)
Это вы уже пишите про сайт GitHub,com и оформление репозитория для совместной работы. Эту тему тоже планирую осветить.
P.S. К сожалению, в свете последних событий блокировка гитхаба не кажется нереалистичным сценарием. Впрочем, на приложение GitHub Desktop из статьи это не повлияет.
С количеством коммитов важно найти золотую середину, как вам будет удобно работать. При рефакторинге я обычно делаю крупные коммиты, и мне там не особо интересно смотреть на все изменения, если проходят все тесты. При добавлении новых фич стараюсь делать по коммиту на каждую фичу или фикс - так потом проще составлять changelog/release notes.
Гигабайтные размеры это действительно проблема, рекомендую очень придирчиво относиться к тому, какие типы файлов вы коммитите, а какие отправляете в игнор. Папку годогенерации, например, со всеми мейк-файлами, бинарниками и т.д. я сразу добавляю в .gitignore. Скомпилированные прошивки - туда же. Если хотите хранить в гите сгенерированный код, лучше отдельно выдирать его из папки кодогенерации и хранить в отдельном репозитории. А сгенерированные бинарники либо прикладываете к релизу (функционал платформ GitHub/GitLab), либо храните просто в папочке, либо можно использовать специальные системы контроля версий для бинарников. Гит он все-таки больше для кода и легких файлов.
Синхронизацию кода между проектами гит тоже упрощает. Как минимум, у каждого коммита есть уникальный хеш-код, который, например, можно указывать в названии или версии прошивки.
Насчет того, что статья поверхностная, это вы верно заметили. В гите еще куча функций, заморочек, методик работы, хороших практик. Тут главное, не бояться начать, а дальше все приходит с практикой. Планирую раскрывать тему дальше в новых статьях.
Эх, жалко раньше не было таких емких статей про Actions, пришлось самому ковыряться.
Я в своем экшене решил извратиться и отдал сборку итогового JS через Vercel на откуп самому GitHub Actions. Он сам собирает готовый экшен и коммитит в релизную ветку, а в исходниках не остается ничего лишнего. Вроде бы и оверкилл, но зато красиво работает:
Моделированием занимаются с тех пор, как появилась математика. Но только благодаря развитию технологий мы постепенно приходим к широкому использованию цифровых двойников.
Очевидно, не до конца вы освоили суть модельно-ориентированного проектирования, раз такое пишите :) Ничего, я объясню.
Сгенерированный код нужно запускать ровно с тем тактом, с которым алгоритм работает в модели, потому что код — это артефакт, производная модели, и расходиться с ней не должен.
Если же нужно сделать алгоритм, исполняемый с произвольным тактом, это в Simulink делается легко, например с помощью Triggered Subsystem, из которой также генерируется код. Если у вас есть лицензия на Embedded Coder, попробуйте. Если нет, можете запросить триал у представителей, они вам и с Миландром помогут разобраться. В сказки верить не обязательно, как и рассказывать их.
Для создания пакетов поддержки микроконтроллеров для MATLAB не нужны палки и костыли, как и доступ к ядру, все описано в документации. И продираться через продукты не надо, они все работают слаженно из коробки.
Придирка к коду тоже странно выглядит, учитывая, что из Simulink без проблем можно генерировать код, исполняемый с произвольным тактом.
А выбрать оптимальный такт работы проще простого благодаря PIL-тестированию, которое работает по нажатию кнопки и позволяет проводить профилирование исполняемого кода на микроконтроллере прямо из Simulink.
Вы если что, всегда можете обратиться к российским представителям, они вас просветят по поводу возможностей. Может быть и модель двигателя более точную покажут.
Это что за пропагандистский заголовок?
Статья должна называться так: "Минцифры поддержало введение запрета на удалённую работу в IT-компаниях для сотрудников, находящихся за границей, работающих над госпроектами"
Мне приходилось экспериментировать с распаковкой бинарных файлов MATLAB, но не очень удачно.
Чтобы поменять код в live-скрипте, мы распаковывали mlx, меняли код во внутреннем m-файле и запаковывали назад в mlx. И по началу оно работало хорошо, но потом начали ловить странные баги в обработанных скриптах. Пришли к выводу, что ручная перепаковка работает ненадежно и лучше ее избегать.
Кстати, не так давно в матлабе появился способ теснее интегрироваться с Git/SVN. Суть в том, что матлаб регистрируется в системе как инструмент для проведения сравнений и слияний:
https://www.mathworks.com/help/matlab/matlab_prog/customize-external-source-control-to-use-matlab-for-comparison-and-merge.html
В таком случае после git diff или git merge автоматически открывается MATLAB/Simulink. Если пользовать гитом из командной строки, то так наверно чуть удобнее.
Еще мне пришлось провести работу над собой и убедить себя, что коммитить бинарные mlx-скрипты не так уж и страшно, если они реально полезны для решения задачи :) Тем более если кодовую базу максимально выносить в m-файлы и собственные библиотеки.
По моему опыту, если вы действительно рассматриваете матлаб для работы, вам не только продлят триал больше чем на месяц, но и помогут разобраться, чтобы быстрее принять решение.
Такой список уже составлен, он покрывает процентов 90% всех файлов: https://github.com/github/gitignore/blob/master/Global/MATLAB.gitignore
На самом деле все усложниться еще больше. Git действительно надо изучать, в том числе методом проб и ошибок. Я статью специально упростил, чтобы снизить порог входа для новичков. Ну и показать, что даже в своих небольших локальных проектах гит полезен.
Важно понимать, что контроль версий - это краеугольный инструмент для разработки. Вести без него даже средний проект на несколько человек это просто самоубийство. То есть можно конечно (что я вижу часто в инженерке), но это приводит к таким проблемам, что лучше весь отдел обучить гиту, чем потерять проект на полпути из-за того что на показательные испытания попала кривая прошивка непонятно кем, когда и из какого кода собранная, в результате устройство сломалось, а что чинить, не понятно (такое тоже видел).
Резервное копирование данных - еще один очень важный инструмент, но контроль версий он конечно не заменяет.
Согласен, тем кто работает на военку противопоказано в принципе заливать свой код в интернет. Лучше использовать локальный GitLab.
К слову я о портале GitHub для хранения кода в статье ничего не писал. Наверно надо пояснить в тексте, что приложение GitHub Desktop никуда само код не отправляет.
Понимаю, о чем вы. В этой статье хотелось не научить полноценно работать с гитом (тут одной статьей не обойдешься), а объяснить инженерам, что гит им необходим, и помочь войти в тему. А дальше обязательно нужно рассказать про ветки и удаленные репозитории.
За рекомендацию Sourcetree спасибо, посмотрю, что там. А работать с гитом только из матлаба мне лично очень больно, не хотелось отпугивать новичков бесконечными контекстными меню :)
Спасибо! Надеюсь будущие статьи на эту тему также будут полезны.
Я сам с гитом 95% времени работаю из приложения GitHub Desktop. Из матлаба разве что проверяю изменения в моделях и приложениях App Designer - тут других вариантов нет.
Вообще, как я понял, сейчас модно встраивать интеграцию с Git во все среды разработки :)
Когда модели симулинк были текстовыми файлами, было поприятнее)
Впрочем, и сейчас в качестве бинарников они весят мало, так что даже старые репозитории с большой историей не отъедают больше нескольких ГБ. А отслеживать изменения через интерфейс Simulink в принципе достаточно удобно, хоть и требует пары лишних телодвижений :)
Это вы уже пишите про сайт GitHub,com и оформление репозитория для совместной работы. Эту тему тоже планирую осветить.
P.S. К сожалению, в свете последних событий блокировка гитхаба не кажется нереалистичным сценарием. Впрочем, на приложение GitHub Desktop из статьи это не повлияет.
Добавлю к тому, что написал kozlyuk.
С количеством коммитов важно найти золотую середину, как вам будет удобно работать. При рефакторинге я обычно делаю крупные коммиты, и мне там не особо интересно смотреть на все изменения, если проходят все тесты. При добавлении новых фич стараюсь делать по коммиту на каждую фичу или фикс - так потом проще составлять changelog/release notes.
Гигабайтные размеры это действительно проблема, рекомендую очень придирчиво относиться к тому, какие типы файлов вы коммитите, а какие отправляете в игнор. Папку годогенерации, например, со всеми мейк-файлами, бинарниками и т.д. я сразу добавляю в .gitignore. Скомпилированные прошивки - туда же. Если хотите хранить в гите сгенерированный код, лучше отдельно выдирать его из папки кодогенерации и хранить в отдельном репозитории. А сгенерированные бинарники либо прикладываете к релизу (функционал платформ GitHub/GitLab), либо храните просто в папочке, либо можно использовать специальные системы контроля версий для бинарников. Гит он все-таки больше для кода и легких файлов.
Синхронизацию кода между проектами гит тоже упрощает. Как минимум, у каждого коммита есть уникальный хеш-код, который, например, можно указывать в названии или версии прошивки.
Насчет того, что статья поверхностная, это вы верно заметили. В гите еще куча функций, заморочек, методик работы, хороших практик. Тут главное, не бояться начать, а дальше все приходит с практикой. Планирую раскрывать тему дальше в новых статьях.
Эх, жалко раньше не было таких емких статей про Actions, пришлось самому ковыряться.
Я в своем экшене решил извратиться и отдал сборку итогового JS через Vercel на откуп самому GitHub Actions. Он сам собирает готовый экшен и коммитит в релизную ветку, а в исходниках не остается ничего лишнего. Вроде бы и оверкилл, но зато красиво работает:
https://github.com/Roslovets-Inc/zip-npm-files
Мне еще с Олегом Бартуновым понравилось о Postgres.
habr.com/ru/post/479624
И о цифровых двойниках с гендиром консалтинговой фирмы
habr.com/ru/post/483148
Сгенерированный код нужно запускать ровно с тем тактом, с которым алгоритм работает в модели, потому что код — это артефакт, производная модели, и расходиться с ней не должен.
Если же нужно сделать алгоритм, исполняемый с произвольным тактом, это в Simulink делается легко, например с помощью Triggered Subsystem, из которой также генерируется код. Если у вас есть лицензия на Embedded Coder, попробуйте. Если нет, можете запросить триал у представителей, они вам и с Миландром помогут разобраться. В сказки верить не обязательно, как и рассказывать их.
Придирка к коду тоже странно выглядит, учитывая, что из Simulink без проблем можно генерировать код, исполняемый с произвольным тактом.
А выбрать оптимальный такт работы проще простого благодаря PIL-тестированию, которое работает по нажатию кнопки и позволяет проводить профилирование исполняемого кода на микроконтроллере прямо из Simulink.
Вы если что, всегда можете обратиться к российским представителям, они вас просветят по поводу возможностей. Может быть и модель двигателя более точную покажут.