Даже работая в одиночку нужна система контроля версий и желательно багтрекер тоже

Я о том и говорю, что понимание этого приходит только с развитием. А ко многим одиночкам не приходит вообще. Такое же принятие/отторжение происходит и со многими другими подходами и технологиями, типа использование/неиспользования РТОС, ММU, Матлаба, или 8-и/32-х битных контроллеров, что и видно из данной темы.

+1. Только в России никто переучиваться не хочет. Как привыкли 30 лет назад работать, так и будут до конца дней Пример syoma очень показателен. Заграницей просто выгонят с работы, а у нас, если чудом такое случится, найдут еще более дурного работодателя, у которого можно продолжать работать своими древними методами.


Жалко, что никто не сказал, что RTOS дисциплинирует. Когда тебе достается проект в несколько десятков тысяч строк (на самом деле это не показатель) совершенно без документации, в котором реализованы свои конечные автоматы, очереди FIFO/LIFO, тратится безумное количество времени, чтобы понять, как это работает. Если вообще возможно понять это полностью.

Та не только...

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

Мне казалось, что это у нас так плохо. Самое обидное, что не только в НИИ и прочих гос. предприятиях, но и во многих частных компаниях, выполняющих гос. заказы. Казалось бы, все карты в руки. Ан нет...


Естественный отбор

Да! Без вариантов.

1. Сложность больших программ обусловлена фундаментальной проблемой программирования: "IF..THEN..ELSE"
2. В "ногодрыганье" микроконтроллеров (даже с использованием RTOS) для профи нет НИЧЕГО сложного.


"А мужики-то не знали"©
Тут не подростки, "не нюхавшие пороху", собрались, а опытнейшние разрабы.
Поэтому не надо тут капитанствовать

Только в том смысле, что программирование "чего-то вообще" не существует. Существуют разные задачи и разные разделы. Одному не нужны операционные системы, потому он два байта и так в ГОТОВЫЙ GSM модуль перешлет, другому вообще мало, что нужно, кроме "матлаба", поскольку работает с ГОТОВЫМИ промышленными контролерами. Кто то балансирует делая свои железные модули, но уже по максимуму натягивая готовый софт... Но кто то все де должен и делает все это "ГОТОВОЕ" для тех, кому становятся ненужными ни операционные системы, ни языки программирования....

о! могу поногодрыгать даже под вындовс

Не кормите очередную реинкарнацию Доктора Туамозеса - он только по пустому трепу выдающийся специалист.

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

Т.е. Вы работаете совсем в другой "весовой категории". Лёгкой

Я не программист-специалист. Любитель. Но эту часть работы никому не отдам (да, собственно, и некому. Беларусь!)
Насчет контроля версий - однозначно, маст хэв. Пользують TortoiseHG, рекомендую.
Насчет РТОС - да, есть смысл. Предпочел бы сделать свою, простенькую. Впрочем, Кейловская устраивает. Надо бы изучить Прототрейдс ( Паша, превед), по-моему, хватило бы. Кому мало - не возражаю. Даже коопервтивной хватило бы. Главное, как ее применить.
А как научиться писать хорошо - смотреть примеры здешних гуру. Записываю в файлики все, что достойно изучения. Здесь мастера.

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

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

Ну хорошо, допустим, запустите вы какой-то "линукс" хоть на аврке, НО,
во первых, для чего? Какие задачи он будет выполнять?
Линукс ставят прежде всего для сетевых систем, веб- серверов, баз данных, или, кому лень делать GUI, навешивают qt и прочее.
Что из этого сможет делать линукс на стм или подобных камнях? Переключать контекст - для этого лучше RTOS, сможете запустить нормальный вэб-сервер? Издеваетесь... Тогда зачем этот костыль на подобных камнях??

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

Они?
https://www.mathworks.com/company/user_stor...the-future.html

А еще в самолетостроении генерируют код: https://www.mathworks.com/company/user_stor...simulators.html

Ну и еще много где: https://www.mathworks.com/company/user_stor...l?q=&page=1

шарп просто отлично работает на стм, и кстати да, спасибо за напомнили обновить

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

Лучше всего начинать с себя

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

У меня возникает тогда резонный вопрос: вы предлагаете вообще на микроконтроллерах класса Cortex-M0, M3, M4, avr, pic писать только одну задачу? Но так не бывает. Обычно более-менее вменяемый девайс кроме выполнения основной задачи (например померить напряжение, как пример мультиметр), должен ещё реагировать на интерфейс пользователя (оперативно, а не с тормозами и задержками), поддерживать связь с компом, если она подключена, опрашивать состояние зарядного устройства. Как минимум - четыре задачи уже есть. Так или иначе (и спорить здесь, мне кажется нет смысла) вам нужна многозадачность. Как вы её реализуете - мэйнлупом, конечными автоматами, поставите четыре камешка, используете RTOS - дело десятое. Но вам придётся её реализовывать. Я делала всеми способами, кроме запайки нескольких физических чипов))) RTOS мне показалось самым удобным из всего тем, что мои задачи - функции с закмнутым циклом. Возникает абстракция - когда каждый цикл выполняется сам по себе (я понимаю, что реально это не так, т.к. ядро одно) и независимо. Удобные сервисы межзадачного взаимодействия позволяют наладить работу. И мне нет нужды заботиться о том, как задаче измерения отдать больше времени, чтобы она отработала свои алгоритмы в реалтайме, но при этом и связь не навернулась. При правильном выборе приортитетов, грамотном использовании железа (прежде всего прерывания, DMA) всё отлично работает. Повторюсь: да, вы можете сделать тоже самое без ОС. Вы даже можете сделать это без микроконтроллера, например на ПЛИС. Можете вообще использовать семейство низкоуровневой логики типа 74hc. И тоже получите тот же результат. Поймите меня правильно, я не говорю, что ОС - панацея. Я лишь удивляюсь, когда про неё говорят "фигня".

Что значит - нормальный? Какой критерия нормальности?

Бог с вами! У себя на работе мы используем FreeRTOS и Linux. Каждый на своём камне, и каждый для решения своего круга задач.

Выше объяснил.


Меня, пожалуйста!

Да, извращенцев много разных бывает: одни С++ в embedded пихают, другие вообще на каком-нибудь ужасе вроде си-диеза (а то и пхытона) калякают...
Насчет калокуба все понятно — это та же абдурина, только уровнем повыше. Но точно так же вместо десятка килобайт генерирует бинарь на сотню. Да еще и простыню совершенно нечитаемого кода.

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

Как пример сложной "железячной" темы: управление нашим телескопом (от нижнего и до верхнего уровней) написано одним-единственным человеком. И я не вижу сложности в написании пары десятков тысяч строк кода одним человеком.

"Сам себя не похвалишь - никто не похвалит"?

Исторя о том "как я сдулся и стал офисным планктоном". А потом такие мыкаются по форумам в поисках чего бы вы думали ???... TFT диплейчиков!
Какой-то когнитивный диссонанс.
Просто разработка - не Ваше. Потому и нет вас на github и не можете вы показать ни одну свою модель в Matlab.

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

А ответ прост. Ма разрабатываем на платформах (более крупная сущность чем фреймворк).
Я один работаю или десять не имеет значения для сложности. Сложность в платформе - как тут уже намекали.

Часть толпы, как понимаю, у syoma занимается разработкой платформы, хотя он это выдает за свой проект.
Но платформы конкурируют. И вся работа Сёмы может пойти в урну.

Я же могу менять платформы как перчатки. В этом плане имею преимущество.


Эдди, ваш безопасный malloc вот в этом месте меня опять здорово повеселил.
Надо признать, что программирование на PI сильно искажает представление о программировании в embedded.

Это враньё, приведите пример. Почему вы измеряете только размер программы? А скорость исполнения кода? А время разработки? А стоимость разработки?

Да любой проект поднимите в одиночку. Только про время разработки не забывайте. За какое время поднимите софт управления векторным анализатором цепей?

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

Нет, это не я


Ну так сами сравните. Я калокубами не пользуюсь.

Если не писать код полностью самому (ну или в команде), то время разработки явно больше будет (пока разберешься во всем, что там автоматы нагенерировали)...
Стоимость разработки я вообще никак не оцениваю, потому как у меня не сдельная оплата. Ну, можете считать, что если что-то я буду месяц разрабатывать, стоимость будет равна 17.5тыр (моя зарплата).

Ну, а в нашем случае то, что сложными вещами занимаются 1-2 человека — не достоинство, а как раз-таки недостаток. Просто специалистов нет. Вот каждый сам и городит себе что-то.

Лет семь. Это немного.

Куча сименсовских, севовских и т.п. приводов (жаль, что все это г. только в мастдайке можно сконфигурировать — здесь получается очень узкое место, поэтому разработка и тормозится сильно). Разные датчики (абсолютные угловые энкодеры, концевики и т.п.).
В принципе, система уже устарела, и нужно заново переделывать. Но все равно основная коммуникация будет, скорее всего, по-старому — по CAN-шине.
В целом получается очень гетерогенная среда, связать компоненты которой иной раз без "через одно место" не получается. И зачастую возникают проблемы, когда железо покупает один человек, а заставить его работать должен другой. И тут выясняется, что протоколы закрытые, железка работает только в "фирменном ПО" под мастдайкой. В общем, таким образом уже не один миллион рублей был просран (извиняюсь за выражение): железку купили, а заставить работать ее невозможно. И железка идет в мусорное ведро.

Это если что-то мелкое, а не шестиметровая дурища.


Не мой. Нет, естественно. Какая, нафиг, сертификация? Зачем???

У разработчика спросите. Пользователям наплевать: лишь бы нормально работало.

Увы, железо закупалось готовое. Лучше бы разрабатывали и его, чтобы система была гомогенная. Подумаешь, еще на 5-7 лет затянулось бы. Зато все было бы прозрачно и понятно. И не требовало бы извращений (скажем, чтобы сконфигурировать привода, нужно искать ноутбук с мастдайкой, ставить туда "фирменное ПО", да еще и читать мануал на полторы-две тысячи страниц, как при помощи мыши это Г. сконфигурировать, вместо того, чтобы быстренько на сях код написать).


Чем же?

Есть многое на свете, друг Горацио (с). Иными словами: не все в этом мире сводится к управлению телескопом, есть задачи и посложнее, где требуются системный и командный подход, хотя, бывает что и один человек их решает, если правильно выбрана подходящая платформа.
Вам же вроде объяснили, что речь идет о конкретных пакетах внутри среды Матлаб и что именно они генерируют на выходе. Или вы о железе в буквальном смысле? Ну так и там матлаб отлично применим для молекулярнх расчетов по теории функционала электронной плотности (DFT)!


У C++ много всяких вкусностей, полезных в embedded.
А C# чем вам не угодил?


а почему обязательно нужно присутствовать на github? Далеко не все желают делиться своими проектами. А многое из того, что есть на github (например, от одного из участников данной темы) я бы вообще постеснялся выкладывать.

Коллеги, а порекомендуйте достойный трекер для команда из 4 - 6 человек с невысоким порогом вхождения?

У вас когнитивный диссонанс просто от того, что у меня есть несколько проектов, начиная от основной работы в Германии, фирмы в Украине и личного проекта умного дома. В некоторых из них несколько разработчиков, в некоторых я один. Как говорят, side code у меня тоже есть. Только он не на github, а на gist. Матлабовские вещи, к сожалению, все на фирмах, поэтому выкладывать их я не имею право. Кстати, вы видели в интернете много других моделей для Матлаб - от всех тех, о которых есть white paper? А там тысячи лицензий и моделей. Вы думаете они просто так по 5000€ за лицензии отваливают?

Я использую Jira - 10$ в месяц. Можно на своем сервере настроить - тогда почти бесплатно.

Вот не надо, а? Более того, я ещё раз настоятельно прошу всех участников прекратить нарушения Правил, ибо тема превратилась в обсуждение друг друга, а не написания программ. Особое предупреждение TSerg-у.
Коллеги, воздержитесь от "меряния достоинствами" и определения "фигнёй" всего того, чем сам не пользуешься. Ребячество какое-то среди взрослых людей.
Не заставляйте прибегать к админ. мерам.

Youtrack

и почему это он вас так пугает ?
вот тут линух запускали на аврке, а если сделать наоборот, шарп запустить на фпга ?

А я не то, что в это теме и на форуме в целом.
Я и в реале не слышал о таком.
Совсем отстал я от прогрессу


Ага. Тут недавно общался с программистом.
Он себя пяткой в грудь бьёт "я уже 20 лет программирую".
И при этом задает вопрос: а что такое процессор и прерывания?
Тут я и выпал в осадок

НедоЯП от мелкомягких? Да тупо потому, что не нужен! Ладно, Страуструп С++ придумал — пользуйтеся, кому ООПщина нужна. Зачем было этот идиотизм выдумывать?
// кстати, ЕМНИП, си-диез до сих пор только в мастдайке работает, а в линуксе лишь через wine.

Лучше бы промолчали.

посмотрите git. (хорошее описание: https://git-scm.com/book/ru/v1 , есть и просто pdf)

Для небольших групп и некрупных проектов (5-10 человек, тысяча своих файлов кода, несколько лет на проект)- мне лично очень нравится. Но точно так же можно и крупные проекты поднимать, не вижу сложностей или ограничений в концепции.
Насколько я понимаю, можно на ГитХабе тоже частные проекты делать, и наверняка еще в куче мест ресурсы дают.
У нас GitLab подняли на своем приватном сервере, им и пользуемся.

Лет 10 назад игрался с SVN (и немного использовал как член команды) - не впечатлило. Гит сильно больше понравился.

Система контроля версий - это не баг-трекер.

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

Например? Что такого вкусного в плюсах для МК, чего нет в обычных сях? Генерируемого бинаря на порядок большего размера? Или потребления оперативы в 2 раза больше? что именно?

Шарп требует использования дотнета, чо считаю вполне не гуд...

На безрыбье- вполне можно и Issues из GitLab использовать. Вполне хватает для отслеживания и обработки багов. Эти Issue линкуются с коммитами и с тагами проекта, так что вполне себе система.
Конечно, иногда хочется большего, но так как минимальная необходимая функциональность уже есть- вопрос установки чего-то более навороченного утыкается в вопрос "а зачем, если и этого хватает".
Как только найду аргументы- тоже побегу устанавливать что-то дополнительное.
У меня вопрос стоит так: если уже используется GitLab, как и что доставить для более красивого трекинга багов? И можно ли при этом не ломать уже работающее?

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

А так повредит кого-то эта "шестиметровая дурища" и свалят всё на вас.


Опять сместили тему на групповуху.

Эффективному разработчику не нужен багтреккер. Баги исправляются сразу же при появлении.
Просто никто не допускет чтобы они существовали дольше суток от момента их обнаружения.

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

Вот если на продажу, тогда — согласен, иной раз потребуют сертификацию изделия. Хотя, я не представляю, кто в России смог бы сертифицировать, скажем, эшелльный спектрограф.


И кто сообщит разработчику об обнаруженном баге? А если ПО используется многими?
В принципе, да — на разработку единичных железяк никакого багтрекера не нужно, но вот на клиентское ПО, работающее с этими железяками, очень даже пригодится. И пулл-риквесты народ слать будет.
Тем и удобен опенсорц: всякое закрытое ПО десятилетиями баги из версии в версию тащит, а в открытом они так долго не держатся.

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

А по-настоящему эффективный разработчик не допускает появления багов. И система контроля версий ему тоже ни к чему.
Он сразу пишет финальную версию. :-)

Напрямую, в машкодах ☺

Ага, пользователи оборудования щас в баг треккер полезут что-то писать.
Да им в суд легче подать.
Или на возврат денег. Думаю чаще всего так про баги и узнают разработчики фирмваре.


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

Если это опенсорс, то будут.
Давно, кстати, меня терзает мысль: почему до сих пор никто не написал фрезерный станок на STM32? Было бы свободное время и куча денег, сам бы занялся этим вопросом. Для начала хотя бы сверлильный станок сделать, чтобы печатные платы сверлить... А то я уже третий год как забил на этот проектик.

Вы не понимаете о чем пишите.
Обычно замечания и баги - это все, что приходит от пользователей, а не только от разработчиков.
У меня есть проект, где незакрыто примерно сотня замечаний (из трехсот). Замечания- разные, от "не работает то-то при таком-то сочетании конфигурационных параметров" до "не выводится надпись Shutdown... во время пересброса telnet командой." или "хорошо бы добавить....". Это не только баги, у этих Issue могут быть разные метки, от "баг" до "сделать до выхода на пенсию".
Никакое замечание невозможно гарантированно устранить в течении суток, так как полная проверка для релиза занимает минимум неделю. И любое изменение влечет за собой полную проверку, иначе это не релиз а всего лишь багфикс.

Я бы сказал, что фраза "Эффективному разработчику не нужен багтреккер" должна быть заменена на "AlexandrY не нужен багтреккер".

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

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

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


Ересь! Изыди, искуситель!
Я с такими антиобщественными явлениями борюсь всю сознательную жизнь, правда, применяя несколько другие термины

+100500
Ничто так не усложняет работу как средства её облегчения.
Мало того, что разработчику нужно держать в голове все нюансы задачи, железа, языка программирования, компилятора, IDE, отладчика, профилировщика, CVS и доксигена.
Так он еще, получается, должен держать в голове все нюансы работы с багтрекером.

Голова распухает от большого объема информации, которую нужно постоянно "иметь в виду"/"держать в голове". Соответственно вероятность ошибки растет

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