Нет, порог входа очень сильно различается. Возьмём ардуино. За 100 рублей плату купил, ide поставил, пример запустил одной кнопочкой, светодиодиками помигал, библиотеку взял, сервоприводом подвигал.
Ну а AVR... Программатор найди, плату найди или сам сделай, фьюзы настрой с риском окирпичивания, пойди пойми как с портами работать, как периферию инициализировать. Уже заинтересованный это сделает. А тот кто присматривается потыкается помыкается, да забьёт. Всегда надо с чего-то начинать, как и с детьми, первые шаги очень важны.
кто писать умел на чем хочешь напишет
Любопытное наблюдение из личной жизни. Все эмберы которые так говорят не умеют писать код. Для них если ты просто МК запустил уже писать код умеешь. А для меня ты умеешь писать код если он поддерживаемый и портируемый, как минимум. Вот вам и разница в восприятии при разных порогах входа
За передающей оптопарой можно еще ответную оптопару которая сигнал готовности гонит.
Воооооот, и вы уверены что нейронка не забудет что у нас там где-то стоит оптопара (или например обратная связь) и если на ней пропал высокий уровень (или сигнал после фильтров вне допусков) то надо выдать предупреждение и потушить всё что не должно работать если что-то произошло на обратной связи. Хотя казалось бы, какая связь между тем что за оптопарой и нашим кодом который вообще другим занимается. А это как раз то самое
переставили стул, а на чердаке открылось окно
Так что увы, модули это правильно, но полностью независимо они работать не могут и это надо учитывать.
Не, статья-то здравая, сам в эмбед попал после того как с ардуино играться начал. А инженеру этому передайте что без преемственности у индустрии не будет развития, я стараюсь как минимум облегчить работу тех кто придёт после. Если стажёр - объяснить так чтобы понял, мне же работать проще будет. Не самая выигрышная стратегия учитывая обстановку, но мне всё равно.
Я вот наверное не могу себя пока что инженером назвать. Часто не хватает инженерного мышления чтобы принять взвешенное решение.
Как и надеяться на то что вообще что-то будет и мы не получим модели по 200 баксов в месяц минимум если вообще получим. Комментаторы, кстати, правы на 100%. Исследователям можете передать что врать надо поменьше, гранты сами себя не отработают.
Я прошу прощения за грубый вопрос, а вы точно инженер? Я вообще-то проектирую систему, архитектуру и пишу ТЗ с учётом языка на котором она будет реализовываться железа на котором будет работать (а это всё выбирается под требования) и сразу прикидываю что уже реализовано из того что надо. Что называется, работаем с тем что имеем. И чтобы понять, а как именно лучше реализовать что-то, уже нужен опыт с реализацией, набитые шишки и так далее. Без опыта реализации можно напроектировать такого, что за голову не возьмёшься.
И что за снобизм, никто себе и не приписывает магические умения. Программирование это в первую очередь проектирование. И только потом реализация. У нас зачастую бывают ситуации когда на проектирование потратили 6 месяцев, а реализовали за пару недель.
Мы, к сожалению, не живём в идеальном мире, не надо тут абстрактных речей. Тут банально достаточно ошибиться при парсинге конфигурации и узнаем мы об этом только когда данные на MQTT увидим. Или забыв что вообще-то при обновлении конфигурации надо остановить опрос по modbus.
Так же и в вашем примере, наводок-то нет, классно, логика отдельно. Но вот то, что часть за оптопарой сгорела нахрен, мы не узнаем. Да, состояние рабочее, мы там что-то считаем, выдаём. А ничего не работает. То есть нужно всё-таки контролировать, что у нас там за оптопарой происходит. Вот вам ещё связь. А ещё нам надо контролировать что мы сигнал правильный выдаём (это в основном ЖД касается). Ещё связь.
Или например оптопару-то мы поставили, а питание развязать забыли.
Типа мы в подвале переставили стул, а на чердаке открылось окно.
Ну да, представьте себе, мы не можем добиться идеального диверситета. Вы можете спокойно вылететь за предел стека задачи FreeRTOS и не узнать об этом пока где-то что-то не упадёт.
каждый производитель точил свои гайки и болты
Ну вот у нас модуль стандартный, вход modbus, выход mqtt, всё по стандартам, та самая гайка, пусть и умная. А что, у нас все гайки и болты одинаково производят? У всех одинаковые технологии, объёмы, производство, материалы?
Поступил я значит так как, вы говорили. Дал даташит, полное описание, даже сказал что точно надо использовать двойную буферизацию, использовал sonnet 4.5, что по итогу:
Правильно проинициализировала периферию
Честно сказала что данные надо сдвинуть в старшую часть чтобы правильно обработался SYNC и дала формулу
Правильно сказала что 2 младших байта перед данными управляющие
Что не так:
Неправильная ширина данных DMA (как данных, так и периферии)
Не догадалась что нет необходимости загружать 24-разрядное слово, по умолчанию управляющая последовательность - нули.
Перепутала HDT и FDT (а это важно для обработки двойной буферизации), ну и ещё мелкие недочёты
В целом если ты с таким сталкивался, проблем не будет от слова совсем. Другое дело что в таком случае проблема решается копипастингом, а если ты хорошо пишешь, у тебя ещё и будет набор функций которые инициализируют предоставленную периферию (нейронка решила сделать это через макросы). Но вот если ты с таким не работал, нейронку легко завести в тупик, когда она будет нести ахинею потому что доступа к железу нет.
Это всё хорошо пока эти строки работают полностью независимо от всего остального. В реальности же эти строки входят в модуль с изменяемым состоянием, который взаимодействует с ещё 5 модулями и меняет их состояние или использует их контекст. Да, слабые связи, но их может быть много и они могут сильно повлиять на работу если упустить какие-то детали.
а когда ии вывалила своих галлюцинаций.
Ну то есть смысла особо нет, потому что всё равно приходится вникать в то что она выплюнула, а тогда максимум на что она годится - это проработка концепции, но не реализация.
Ну, собственно о чём я и говорил выше, дьявол кроется в деталях, особенно если мы говорим про контроллеры и ОСОБЕННО если он ещё и взаимодействует с каким-то железом.
Недавно случай забавный был - ЦАП 16-разрядный китайский, работает только один канал, интерфейс похож на i2s и требуется 8 стартовых бит управления, данные защёлкиваются по импульсу на WS. Чтобы оно нормально работало с штатным i2s с dma (скорость большая, 48кгц), нам пришлось делать циклический сдвиг данных, так как i2s контроллера выдаёт данные на левый-правый канал по 16 бит, переставляя 32-бит данные dma.
У нас, как раз чтобы по минимуму писать шаблонный код для периферии, он весь вынесен в отдельные модули, зачастую это просто инициализация. Все модули инициализации написаны наподобие linux драйверов с мапами периферии которая задействована в работе модуля, по которым периферия и инициализируется, совершенно стандартно, и это пишется один раз под контроллер который мы хотим использовать.
Мне, кстати говоря, в принципе нравится код писать. Любой. Работа с железом, логика, внесение изменений, неважно, мне просто это нравится. Находить какие-то мелочи, особенности работы, тонкости которые всплывают в процессе, нетривиальные конструкции, хитрые методы и разные возможности для упрощения. Мне просто интересно, да и в работе такой подход помогает - там на каждую строчку должно быть обоснование, так как от этого зависит безопасность людей (буквально).
Тоже довелось много на чём писать, но, во-первых, речь по хобби проекты. Какой смысл в создании чего-то не своими руками как хобби, очень сомнительная затея как по мне.
А вот написание ТЗ просто на русском языке с указанием граничных условий
...очень хорошо работает до тех пор пока нейронка не начинает писать код. Я вот что заметил - внимательности к деталям у них ноль. Зачастую банально в индексах массива ошибаются, что-то выдумывают и так далее. Не говоря уже о проблемах с потерей контекста на дальней дистанции. Особенно забавно когда ИИ просто выдумывает функции SDK когда ты буквально дал на него ссылку. Дьявол кроется в деталях, как говорится.
Мало того - такая структурированная и четкая постановка задачи практически без ошибок переводится современными ИИ в код для контроллера.
Чего я ни разу не видел. В небольшом проекте да, возможно. В приведённом мной примере больше 70 файлов и 10к строк кода, не считая наших внутренних библиотек (и то это небольшой проект, у нас обычно просто описание работы прибора это документ на 300 страниц). Даже учитывая что у нас модульная архитектура, связи и особенности реализации очень легко потерять. Опять же, дьявол кроется в деталях.
ТЗ, кстати говоря, у нас составляется настолько подробно что описание кода который просто контролирует схему узла защиты от КЗ это 3 страницы с подробнейшим описанием и ссылками на схемы, даже блок-схема алгоритма работы есть - это ТЗ потом ляжет в основу описания принципа работы и доказательства безопасности, поэтому и пишем так подробно. Зато код потом пишется ОЧЕНЬ быстро.
мыслимых и немыслимых комбинациях внешних условий и поломок
Вот поэтому я её и не люблю, хоть и кормит меня работа с безопасным оборудованием. Банальный человеческий фактор, очень легко упустить какую-то делать или мелочь, которая потом может привести к неожиданным последствиям. А ещё я травмирован работой над доказательствами безопасности, процесс очень сложный, долгий, муторный и незаметный. Два года разрабатываем прибор и три года тестируем и дорабатываем.
Такая же фигня, только с самой ардуино. Попала она ко мне в руки впервые когда я вот буквально поступил в универ, всё завертелось, меня затянуло. Написал пару строчек, и вот лампочки мигают, моторчик вращается, данные по serial идут, офигеть, магия. Потом начал потихоньку изучать, а как же это работает под капотом - сказалось любопытство. И тут пошёл работать ещё будучи студентом (ещё сказалось образование - связь).
Даже не знаю попал бы я в эмбед без этого или нет.
Это всё хорошо, только вот задача с кучей готовых решений на мега популярном контроллере. Мы тут недавно делали медиаконвертер modbus rtu/mqtt под свои задачи. Примерно так: две линии RTU, до 6 приборов на линии, минимальный период опроса 200мс ± 1мс, если больше то кратно 200, конфигурация и обновление прошивки по TCP, хранение конфигураций в eeprom, работа с float16 и сдвоенными регистрами, трансляция modbus команд в первую линию RS, отладка по USB. Работало на китайском чипе на cortex-m4f (но это неважно, у нас разделена логика на C++ и периферия на C) с FreeRTOS.
Максимум на что хватило Sonnet 4 это написать получение json конфигурации и её парсинг на lwjson (и то потом пришлось переписывать) и работа с файловой системой для хранения конфигураций. Все решения не соответствовали требованиям вообще от слова совсем или просто не работали. Решения по архитектуре она, конечно, предлагала весьма правдоподобные, но вот реализация примерно никакая.
Имхо, это единственное на что годятся нейронки - обсудить архитектуру, накидать прототип и сделать всё самому, уточняя какие-то моменты по ходу дела.
но в качестве хобби или сайд проектов - имеет право на жизнь
Можно, а зачем? Я вот люблю код писать, и не очень люблю отладку, а у меня забирают то, что я люблю, оставляя делать то, что я не люблю. Другое дело если тебе что-то нужно, но ты не знаешь как это сделать.
оказался в нужное время в нужном месте, чтобы найти хорошего партнёра.
Да. Подходящего тебе человека и правда сложно найти (статистика разводов соврать не даст). Но если ты сидишь дома и ни с кем не общаешься, понятное дело что этот подходящий человек тебе на голову не свалится. Это очевидно, чтобы кого-то найти, надо общаться с людьми и уметь останавливаться. Подходящий - не значит лучший. Ну а там уже диапазон зависит от врождённого и приобретённого - обаяние, внешность, харизма (на самом деле достаточно быть ухоженным и не вести себя как мудак), когда уже друг друга получше узнаете - личность.
проектами, математикой и стилем жизни, когда я почти 24/7 дома и никуда не хожу.
Жесть, прям меня описали, литерали ми. Жаль что я прикладываю все усилия чтобы чего-то добиться в этой жизни, потому что начинал с не самыми лучшими исходными и приходится тянуть работу и учёбу. А ведь мог бы с девчонками тусить, как мой товарищ, которому родители выбили целевое и оплачивали его проживание, а потом и квартиру купили.
И что вы прицепились к этому равенству, нет его и не будет. Но понимать где ты находишься и какие карты на руках надо чтобы правильно их разыграть. И поэтому о неравенстве говорить надо, но не так, как это делают леваки (по крайней мере от них часто бред слышу).
они тоже про отказ от (или отсутствие изначально) личной ответственности.
Прошу прощения, малость в ветке запутался, виноват.
Наличие навыков — не бинарный признак.
Согласен, навыки описываются спектром. Вы можете быть реально хороши, но меркнуть на фоне конкурентов.
Я перестаю понимать, спорите вы со мной или соглашаетесь.
Просто обсуждаю интересную тему. Правда где-то посередине, и в книгах Майкла Сэндела, про которые я говорил, как раз проблема рассматривается с разных точек зрения. С одной стороны, отказ от ответственности ведёт к апатии, обнищанию и потерю агентности о которой вы говорили. С другой стороны, предложенный вами вариант может приводить к культу достигаторства со всеми вытекающими.
А если усилия не прикладывать, то на какой уровень вы с хреновых исходных выйдете?
Окажетесь в ещё более глубокой заднице, потому что чем ближе дно, тем больше усилий надо прикладывать чтобы сохранить хотя бы тот же уровень. Знаю не понаслышке.
рассказы о неравенстве условий, делают хуже
Спорно. Если мы оправдываем неравенством отказ от ответственности, это и правда делает хуже. Но если ты понимаешь что тебе надо приложить больше усилий, чтобы выйти на какой-то уровень, чем кто-то с лучшими условиями чем у тебя, это позволяет лучше расставить приоритеты и правильнее распорядиться тем что уже есть.
Я просто ещё молод и вопрос, как распорядиться своей жизнью и временем для меня очень важен. Кстати, было интересно читать ваши мысли.
Обычная геометрическая задачка. Известно расстояние до точки (2см), известен угол (угол обзора камеры), получаете два прямоугольных треугольника. Известен один катет (2см) и прилежащий угол (обычно такие камеры имеют 70-110 градусов обзора, берём половину), надо найти другой катет. Полученное значение разделить на количество пикселей камеры (тут сказано). Получите примерный размер пикселя, для распознавания надо 2-3 пикселя. Умножаем и получаем диаметр проволоки.
Вроде нормально объяснил, я бы сразу ответ сказал, да записать негде :)
Слышал о такой, только она тут ни к селу ни к городу. Там больше про отказ от ответственности и виктимизацию. А в "оказался в нужном месте в нужное время" почему-то принято опускать её начало — "нужный человек оказался в нужном месте в нужное время", так что поздравляю с победой над соломенным чучелом.
Просто успех это не только про старания и умения, но и про везение в том числе, в той или иной мере. И самое важное - без одного нет и другого. Если навыков нет, везение не поможет. Если навыки есть, приложено много стараний, но ты не добился ничего, только тогда можно говорить что тебе не повезло. И то, термин "успех" применять к получению заветной работы программиста идея сомнительная, в самой книге речь про маргиналов всё-таки.
Вообще, имхо, книга ОЧЕНЬ спорная. Она не учитывает ни конкуренцию, ни стартовые условия. В условиях конкуренции не бывает вечных победителей, а с хреновыми исходными нужно больше усилий чтобы хотя бы на средний уровень выйти. Слышали про воронку возможностей?
Раз уж мы тут книжками разбрасываемся (хотя я терпеть не могу когда это не в форме искреннего совета), советую "Справедливость" Майкла Сэндела (она на русском есть), или "The Tyranny of Merit: What's Become of the Common Good?"
В общем, что то, что то, херня полная, а правда, как всегда, где-то посередине
Хочу заметить, опыт работы в весьма узкой области, а учитывая что сейчас даже кандидатам с опытом про пет-проекты говорят... Ну так, тревожно мне малость, всё-таки сам по себе не так давно жить начал. Да и работа мне нравится. Понятное дело, если что, голодать не буду, но потерять приятную мне работу, где у меня есть опыт и навыки, было бы досадно. Да и смена отрасли всегда ведёт к снижению доходов.
Просто пытаюсь понять правильный ли я выбор сделал, поэтому и переживаю - пока что есть возможность изменить всё с минимальными потерями.
Куда его продвигали, он ещё не вышел из экспериментальной стадии, там даже 0.1 версии нет.
Нет, порог входа очень сильно различается. Возьмём ардуино. За 100 рублей плату купил, ide поставил, пример запустил одной кнопочкой, светодиодиками помигал, библиотеку взял, сервоприводом подвигал.
Ну а AVR... Программатор найди, плату найди или сам сделай, фьюзы настрой с риском окирпичивания, пойди пойми как с портами работать, как периферию инициализировать. Уже заинтересованный это сделает. А тот кто присматривается потыкается помыкается, да забьёт. Всегда надо с чего-то начинать, как и с детьми, первые шаги очень важны.
Любопытное наблюдение из личной жизни. Все эмберы которые так говорят не умеют писать код. Для них если ты просто МК запустил уже писать код умеешь. А для меня ты умеешь писать код если он поддерживаемый и портируемый, как минимум. Вот вам и разница в восприятии при разных порогах входа
Воооооот, и вы уверены что нейронка не забудет что у нас там где-то стоит оптопара (или например обратная связь) и если на ней пропал высокий уровень (или сигнал после фильтров вне допусков) то надо выдать предупреждение и потушить всё что не должно работать если что-то произошло на обратной связи. Хотя казалось бы, какая связь между тем что за оптопарой и нашим кодом который вообще другим занимается. А это как раз то самое
Так что увы, модули это правильно, но полностью независимо они работать не могут и это надо учитывать.
Не, статья-то здравая, сам в эмбед попал после того как с ардуино играться начал. А инженеру этому передайте что без преемственности у индустрии не будет развития, я стараюсь как минимум облегчить работу тех кто придёт после. Если стажёр - объяснить так чтобы понял, мне же работать проще будет. Не самая выигрышная стратегия учитывая обстановку, но мне всё равно.
Я вот наверное не могу себя пока что инженером назвать. Часто не хватает инженерного мышления чтобы принять взвешенное решение.
Как и надеяться на то что вообще что-то будет и мы не получим модели по 200 баксов в месяц минимум если вообще получим. Комментаторы, кстати, правы на 100%. Исследователям можете передать что врать надо поменьше, гранты сами себя не отработают.
Я прошу прощения за грубый вопрос, а вы точно инженер? Я вообще-то проектирую систему, архитектуру и пишу ТЗ с учётом языка на котором она будет реализовываться железа на котором будет работать (а это всё выбирается под требования) и сразу прикидываю что уже реализовано из того что надо. Что называется, работаем с тем что имеем. И чтобы понять, а как именно лучше реализовать что-то, уже нужен опыт с реализацией, набитые шишки и так далее. Без опыта реализации можно напроектировать такого, что за голову не возьмёшься.
И что за снобизм, никто себе и не приписывает магические умения. Программирование это в первую очередь проектирование. И только потом реализация. У нас зачастую бывают ситуации когда на проектирование потратили 6 месяцев, а реализовали за пару недель.
Обожаю это чувство когда делаешь что-то на модели в матлабе или мультисиме/лтспайс, собираешь железку, а она не работает, мммм
Мне вот одно интересно, это же сколько будет стоить доступ к такой вот вундервафле, кто и на какие шиши будет всем этим заниматься.
Мы, к сожалению, не живём в идеальном мире, не надо тут абстрактных речей. Тут банально достаточно ошибиться при парсинге конфигурации и узнаем мы об этом только когда данные на MQTT увидим. Или забыв что вообще-то при обновлении конфигурации надо остановить опрос по modbus.
Так же и в вашем примере, наводок-то нет, классно, логика отдельно. Но вот то, что часть за оптопарой сгорела нахрен, мы не узнаем. Да, состояние рабочее, мы там что-то считаем, выдаём. А ничего не работает. То есть нужно всё-таки контролировать, что у нас там за оптопарой происходит. Вот вам ещё связь. А ещё нам надо контролировать что мы сигнал правильный выдаём (это в основном ЖД касается). Ещё связь.
Или например оптопару-то мы поставили, а питание развязать забыли.
Ну да, представьте себе, мы не можем добиться идеального диверситета. Вы можете спокойно вылететь за предел стека задачи FreeRTOS и не узнать об этом пока где-то что-то не упадёт.
Ну вот у нас модуль стандартный, вход modbus, выход mqtt, всё по стандартам, та самая гайка, пусть и умная. А что, у нас все гайки и болты одинаково производят? У всех одинаковые технологии, объёмы, производство, материалы?
Поступил я значит так как, вы говорили. Дал даташит, полное описание, даже сказал что точно надо использовать двойную буферизацию, использовал sonnet 4.5, что по итогу:
Правильно проинициализировала периферию
Честно сказала что данные надо сдвинуть в старшую часть чтобы правильно обработался SYNC и дала формулу
Правильно сказала что 2 младших байта перед данными управляющие
Что не так:
Неправильная ширина данных DMA (как данных, так и периферии)
Не догадалась что нет необходимости загружать 24-разрядное слово, по умолчанию управляющая последовательность - нули.
Перепутала HDT и FDT (а это важно для обработки двойной буферизации), ну и ещё мелкие недочёты
В целом если ты с таким сталкивался, проблем не будет от слова совсем. Другое дело что в таком случае проблема решается копипастингом, а если ты хорошо пишешь, у тебя ещё и будет набор функций которые инициализируют предоставленную периферию (нейронка решила сделать это через макросы). Но вот если ты с таким не работал, нейронку легко завести в тупик, когда она будет нести ахинею потому что доступа к железу нет.
Это всё хорошо пока эти строки работают полностью независимо от всего остального. В реальности же эти строки входят в модуль с изменяемым состоянием, который взаимодействует с ещё 5 модулями и меняет их состояние или использует их контекст. Да, слабые связи, но их может быть много и они могут сильно повлиять на работу если упустить какие-то детали.
Ну то есть смысла особо нет, потому что всё равно приходится вникать в то что она выплюнула, а тогда максимум на что она годится - это проработка концепции, но не реализация.
Ну, собственно о чём я и говорил выше, дьявол кроется в деталях, особенно если мы говорим про контроллеры и ОСОБЕННО если он ещё и взаимодействует с каким-то железом.
Недавно случай забавный был - ЦАП 16-разрядный китайский, работает только один канал, интерфейс похож на i2s и требуется 8 стартовых бит управления, данные защёлкиваются по импульсу на WS. Чтобы оно нормально работало с штатным i2s с dma (скорость большая, 48кгц), нам пришлось делать циклический сдвиг данных, так как i2s контроллера выдаёт данные на левый-правый канал по 16 бит, переставляя 32-бит данные dma.
У нас, как раз чтобы по минимуму писать шаблонный код для периферии, он весь вынесен в отдельные модули, зачастую это просто инициализация. Все модули инициализации написаны наподобие linux драйверов с мапами периферии которая задействована в работе модуля, по которым периферия и инициализируется, совершенно стандартно, и это пишется один раз под контроллер который мы хотим использовать.
Мне, кстати говоря, в принципе нравится код писать. Любой. Работа с железом, логика, внесение изменений, неважно, мне просто это нравится. Находить какие-то мелочи, особенности работы, тонкости которые всплывают в процессе, нетривиальные конструкции, хитрые методы и разные возможности для упрощения. Мне просто интересно, да и в работе такой подход помогает - там на каждую строчку должно быть обоснование, так как от этого зависит безопасность людей (буквально).
Тоже довелось много на чём писать, но, во-первых, речь по хобби проекты. Какой смысл в создании чего-то не своими руками как хобби, очень сомнительная затея как по мне.
...очень хорошо работает до тех пор пока нейронка не начинает писать код. Я вот что заметил - внимательности к деталям у них ноль. Зачастую банально в индексах массива ошибаются, что-то выдумывают и так далее. Не говоря уже о проблемах с потерей контекста на дальней дистанции. Особенно забавно когда ИИ просто выдумывает функции SDK когда ты буквально дал на него ссылку. Дьявол кроется в деталях, как говорится.
Чего я ни разу не видел. В небольшом проекте да, возможно. В приведённом мной примере больше 70 файлов и 10к строк кода, не считая наших внутренних библиотек (и то это небольшой проект, у нас обычно просто описание работы прибора это документ на 300 страниц). Даже учитывая что у нас модульная архитектура, связи и особенности реализации очень легко потерять. Опять же, дьявол кроется в деталях.
ТЗ, кстати говоря, у нас составляется настолько подробно что описание кода который просто контролирует схему узла защиты от КЗ это 3 страницы с подробнейшим описанием и ссылками на схемы, даже блок-схема алгоритма работы есть - это ТЗ потом ляжет в основу описания принципа работы и доказательства безопасности, поэтому и пишем так подробно. Зато код потом пишется ОЧЕНЬ быстро.
Вот поэтому я её и не люблю, хоть и кормит меня работа с безопасным оборудованием. Банальный человеческий фактор, очень легко упустить какую-то делать или мелочь, которая потом может привести к неожиданным последствиям. А ещё я травмирован работой над доказательствами безопасности, процесс очень сложный, долгий, муторный и незаметный. Два года разрабатываем прибор и три года тестируем и дорабатываем.
Такая же фигня, только с самой ардуино. Попала она ко мне в руки впервые когда я вот буквально поступил в универ, всё завертелось, меня затянуло. Написал пару строчек, и вот лампочки мигают, моторчик вращается, данные по serial идут, офигеть, магия. Потом начал потихоньку изучать, а как же это работает под капотом - сказалось любопытство. И тут пошёл работать ещё будучи студентом (ещё сказалось образование - связь).
Даже не знаю попал бы я в эмбед без этого или нет.
Это всё хорошо, только вот задача с кучей готовых решений на мега популярном контроллере. Мы тут недавно делали медиаконвертер modbus rtu/mqtt под свои задачи. Примерно так: две линии RTU, до 6 приборов на линии, минимальный период опроса 200мс ± 1мс, если больше то кратно 200, конфигурация и обновление прошивки по TCP, хранение конфигураций в eeprom, работа с float16 и сдвоенными регистрами, трансляция modbus команд в первую линию RS, отладка по USB. Работало на китайском чипе на cortex-m4f (но это неважно, у нас разделена логика на C++ и периферия на C) с FreeRTOS.
Максимум на что хватило Sonnet 4 это написать получение json конфигурации и её парсинг на lwjson (и то потом пришлось переписывать) и работа с файловой системой для хранения конфигураций. Все решения не соответствовали требованиям вообще от слова совсем или просто не работали. Решения по архитектуре она, конечно, предлагала весьма правдоподобные, но вот реализация примерно никакая.
Имхо, это единственное на что годятся нейронки - обсудить архитектуру, накидать прототип и сделать всё самому, уточняя какие-то моменты по ходу дела.
Можно, а зачем? Я вот люблю код писать, и не очень люблю отладку, а у меня забирают то, что я люблю, оставляя делать то, что я не люблю. Другое дело если тебе что-то нужно, но ты не знаешь как это сделать.
Да. Подходящего тебе человека и правда сложно найти (статистика разводов соврать не даст). Но если ты сидишь дома и ни с кем не общаешься, понятное дело что этот подходящий человек тебе на голову не свалится. Это очевидно, чтобы кого-то найти, надо общаться с людьми и уметь останавливаться. Подходящий - не значит лучший. Ну а там уже диапазон зависит от врождённого и приобретённого - обаяние, внешность, харизма (на самом деле достаточно быть ухоженным и не вести себя как мудак), когда уже друг друга получше узнаете - личность.
Жесть, прям меня описали, литерали ми. Жаль что я прикладываю все усилия чтобы чего-то добиться в этой жизни, потому что начинал с не самыми лучшими исходными и приходится тянуть работу и учёбу. А ведь мог бы с девчонками тусить, как мой товарищ, которому родители выбили целевое и оплачивали его проживание, а потом и квартиру купили.
И что вы прицепились к этому равенству, нет его и не будет. Но понимать где ты находишься и какие карты на руках надо чтобы правильно их разыграть. И поэтому о неравенстве говорить надо, но не так, как это делают леваки (по крайней мере от них часто бред слышу).
Прошу прощения, малость в ветке запутался, виноват.
Согласен, навыки описываются спектром. Вы можете быть реально хороши, но меркнуть на фоне конкурентов.
Просто обсуждаю интересную тему. Правда где-то посередине, и в книгах Майкла Сэндела, про которые я говорил, как раз проблема рассматривается с разных точек зрения. С одной стороны, отказ от ответственности ведёт к апатии, обнищанию и потерю агентности о которой вы говорили. С другой стороны, предложенный вами вариант может приводить к культу достигаторства со всеми вытекающими.
Окажетесь в ещё более глубокой заднице, потому что чем ближе дно, тем больше усилий надо прикладывать чтобы сохранить хотя бы тот же уровень. Знаю не понаслышке.
Спорно. Если мы оправдываем неравенством отказ от ответственности, это и правда делает хуже. Но если ты понимаешь что тебе надо приложить больше усилий, чтобы выйти на какой-то уровень, чем кто-то с лучшими условиями чем у тебя, это позволяет лучше расставить приоритеты и правильнее распорядиться тем что уже есть.
Я просто ещё молод и вопрос, как распорядиться своей жизнью и временем для меня очень важен. Кстати, было интересно читать ваши мысли.
Обычная геометрическая задачка. Известно расстояние до точки (2см), известен угол (угол обзора камеры), получаете два прямоугольных треугольника. Известен один катет (2см) и прилежащий угол (обычно такие камеры имеют 70-110 градусов обзора, берём половину), надо найти другой катет. Полученное значение разделить на количество пикселей камеры (тут сказано). Получите примерный размер пикселя, для распознавания надо 2-3 пикселя. Умножаем и получаем диаметр проволоки.
Вроде нормально объяснил, я бы сразу ответ сказал, да записать негде :)
Слышал о такой, только она тут ни к селу ни к городу. Там больше про отказ от ответственности и виктимизацию. А в "оказался в нужном месте в нужное время" почему-то принято опускать её начало — "нужный человек оказался в нужном месте в нужное время", так что поздравляю с победой над соломенным чучелом.
Просто успех это не только про старания и умения, но и про везение в том числе, в той или иной мере. И самое важное - без одного нет и другого. Если навыков нет, везение не поможет. Если навыки есть, приложено много стараний, но ты не добился ничего, только тогда можно говорить что тебе не повезло. И то, термин "успех" применять к получению заветной работы программиста идея сомнительная, в самой книге речь про маргиналов всё-таки.
Вообще, имхо, книга ОЧЕНЬ спорная. Она не учитывает ни конкуренцию, ни стартовые условия. В условиях конкуренции не бывает вечных победителей, а с хреновыми исходными нужно больше усилий чтобы хотя бы на средний уровень выйти. Слышали про воронку возможностей?
Раз уж мы тут книжками разбрасываемся (хотя я терпеть не могу когда это не в форме искреннего совета), советую "Справедливость" Майкла Сэндела (она на русском есть), или "The Tyranny of Merit: What's Become of the Common Good?"
В общем, что то, что то, херня полная, а правда, как всегда, где-то посередине
Хочу заметить, опыт работы в весьма узкой области, а учитывая что сейчас даже кандидатам с опытом про пет-проекты говорят... Ну так, тревожно мне малость, всё-таки сам по себе не так давно жить начал. Да и работа мне нравится. Понятное дело, если что, голодать не буду, но потерять приятную мне работу, где у меня есть опыт и навыки, было бы досадно. Да и смена отрасли всегда ведёт к снижению доходов.
Просто пытаюсь понять правильный ли я выбор сделал, поэтому и переживаю - пока что есть возможность изменить всё с минимальными потерями.