Comments 39
Хоть не назвал бы себя новичком, но прочитал с удовольствием, прям жиза!
Можно ещё добавить про «технический долг» и его последствия, особенно в контексте стартапа
Можно ещё добавить про «технический долг» и его последствия, особенно в контексте стартапа
Про технический долг вроде была статья, хотя под этим термином, насколько я понимаю, подразумевают два процесса: взятие кредита для разработки «железной» части или о плохой продуманности системы.
Вот была ситуация, когда коллега поправил номинал резистора вручную (только value, а component name и marking оставил без изменений), хотя 100500 раз просила так не делать, лучше оставить пометку или полностью заменить компонент. Но нет. В итоге закупили резисторов не того номинала и хорошо, что случайно в который раз решила проверить перечень, что все куплено и уже в пути. А если другой резистор, так еще и монтажную документацию менять. Сплошная боль. Но это, наверное, самый страшный мой «технический долг» на данный момент.
И спасибо =)
Вот была ситуация, когда коллега поправил номинал резистора вручную (только value, а component name и marking оставил без изменений), хотя 100500 раз просила так не делать, лучше оставить пометку или полностью заменить компонент. Но нет. В итоге закупили резисторов не того номинала и хорошо, что случайно в который раз решила проверить перечень, что все куплено и уже в пути. А если другой резистор, так еще и монтажную документацию менять. Сплошная боль. Но это, наверное, самый страшный мой «технический долг» на данный момент.
И спасибо =)
В жизненном цикле проекта, самое простое и легкое — это разработка ПП, чуть сложнее — разработка ПО, а самое сложное и дорогое — корпус устройства. Чтобы было технологично и в то же время концептуально — куча итераций.
Каждый специалист считает, что его работа самая сложная. Есть много устройств, где корпус был самой меньшей проблемой. Мне, как конструктору ПП, не очень, когда сеют подобные высказывания среди народа, потому что потом заказчики начинают «а почему так долго, а почему то, а почему се». Потому и описан цикл разработки ПП, на этом этапе закладывается элементная база и ошибка при выборе или при трассировке может стоить очень и очень дорого, кроме того нужно балансировать на стыке средств и технологий производства.
Поддерживаю, мне кажется, что самое главное в цикле, это чтобы цикл работал ровно без резких ускорений и простоев. Сложнее тому, кому подстраиваться больше надо.
P.S. В примечание 2 опечатка в слове «идеи».
P.S. В примечание 2 опечатка в слове «идеи».
"Печень элементов" и "полоскайте программиста" — тоже как-то двузначно.
То ли прополоскайте ему мозги (метод Кнута), то ли облАскайте (пряником). Но кавычек не хватает ПМСМ.
Вопрос автору — это в России или где такое живое пр-во ещё сохранилось?
Если захотеть машину времени и нарисовать её цикл разработки — тоже получится? :)
трассироваки — ??
Или к этому сайту надо приделать Ctrl+Enter про опечатки, чтоб он не был машиной для подавления угнетенных (кармой) классов. https://orphus.ru/
Методы принуждения на ваше усмотрение, просто рекомендации с благими намерениями. Коллеге достался проект, думал разберется в коде предшественника, где, по словам начальства, отличный алгоритм. А в итоге оказалось, что все работало на чистом слове. А время потеряно.
В Украине. Работы достаточно, дефицит специалистов и все такое.
За опечатки каюсь, поправила, благодарю.
В Украине. Работы достаточно, дефицит специалистов и все такое.
За опечатки каюсь, поправила, благодарю.
Спасибо, поправила. Много раз вычитываешь и все равно что-то не замечаешь. Каюсь
Я думаю, что вы измените своё мнение относительно простоты изготовления корпуса, когда посмотрите цены на пресс-формы и их изготовление. Если корпус покупной, то вы правы. Но устройство в покупном корпусе не продаст себя само. А если делать устройство не для продаж, то есть ли смысл его делать вообще?
Надо понимать, что один ваш неверный шаг создаст проблем другим, кто идёт после вас в цепочке. Тем же конструкторам корпуса. Оснастку переделай, пресс-формы переделай, инструмент поменяй, и т.д. Для этого и сделаны CAD программы, чтобы заранее находить проблемные моменты и несовпадения интересов.
Надо понимать, что один ваш неверный шаг создаст проблем другим, кто идёт после вас в цепочке. Тем же конструкторам корпуса. Оснастку переделай, пресс-формы переделай, инструмент поменяй, и т.д. Для этого и сделаны CAD программы, чтобы заранее находить проблемные моменты и несовпадения интересов.
Я не утверждаю, что это всегда просто, абсолютно все зависит от содержимого проекта. Для тех же релюшек покупают готовые корпуса и они продаются. Электроника бывает разная. Для промежуточного этапа устройства порой тоже нужен корпус. Но зачем делать пресс-форму, если количество небольшое и от него требуют не красочности, а функциональности?
Соглашусь в тем, что оригинальный корпус (оснастка, материалы, подрядчик или собственное производство) если и не перевесит «схема+плата+ПО», то, по крайней мере, составит им существенную конкуренцию.
Эт'неправильные электронные устройства, и у них неправильный электронный мёд…
Прочитал с удовольствием, спасибо за интересное изложение и охват обширной и сложной темы! Буду ждать новых публикаций.
Идея разве не от заказчика должна исходить?
Все примерно так, только вы смешали разные процессы — разработка, подготовка к производству и само производство. В общем-то ГОСТ еще с советских времен описывают всю цепочку. Если разработка еще туда-сюда можно и не сильно соблюдать, то подготовка к производству и производство настоятельно рекомендуется вести по ГОСТ, потому что там предусмотрен обход максимального количество «подводных камней» и просто минимизирует издержки производства в дальнейшем. Тот, кто поучаствовал в полном цикле начинает понимать — этих «камней» там гигантское количество. И написать по этой теме можно еще десятка два статей.
Да, я так понимаю ваш опыт ограничивает малой серий, сотня-другая штук.
Кстати, вы забыли еще два важнейших этапа производства — контроль(ОТК) и упаковка.
Да, я так понимаю ваш опыт ограничивает малой серий, сотня-другая штук.
Кстати, вы забыли еще два важнейших этапа производства — контроль(ОТК) и упаковка.
Все примерно так, только вы смешали разные процессы — разработка, подготовка к производству и само производствоЯ постаралась описать процессы относящиеся к железной части поскольку в университетах с этим не знакомят и много людей не представляет себе в принципе эту «карту сокровищ».
В общем-то ГОСТ еще с советских времен описывают всю цепочкуГОСТ вещь своеобразная и не всегда и не ко всему применима. Был опыт написания стандарта работы предприятия поскольку ГОСТ в большинстве своем многое усложнял. В том числе и шаблоны использовали свои.
Почитала ГОСТ 15 (может не тот?), но конкретики мало. Всегда проще, когда кто-то обычными словами поясняет.
Да, я так понимаю ваш опыт ограничивает малой серий, сотня-другая штукВ общем то да, но в недалеком будущем будет масштабирование производства, но перед этим нужно еще пару макетов (макетов много не бывает :D).
Кстати, вы забыли еще два важнейших этапа производства — контроль(ОТК) и упаковкаА мы же не обсуждаем готовый продукт для продажи. Это некое абстрактное железо на невесомой спице в вакууме. Хотя вот процесс контроля меня саму немного беспокоит, но с этим нужно на тостер сходить.
Был опыт написания стандарта работы предприятия поскольку ГОСТ в большинстве своем многое усложнял.
Усложнение потом окупается многократно. Я сам когда-то сопротивлялся и не понимал, но когда сопровождал настоящее производство, понял — лучше перебдеть, чем недобдеть :)
В общем случае, какими-то можно пренебречь, главное понимать.
разработка ГОСТ 2.103, производство ГОСТ 14, 15
Хотя вот процесс контроля меня саму немного беспокоит
Однако, этот вопрос один из важнейших — проверить создало ли производство то, что вы от него ожидали?
А что вы ожидали? Какие параметры определяют, что изделие работоспособно, какие необходимо контролировать и в каких условиях? и т.д. Для этого на изделие пишутся ТУ(технические условия) по ГОСТ 2.114
Да и в процессе производства необходимо контролировать, там уже ОТК и еще какой-то ГОСТ :)
И всё же на предприятиях разного уровня по разному реализован процесс разработки.
Из моей практики, больше всего времени отнимает составление технического облика изделия (исследовательская работа, проработка различных вариантов решения задачи, защита проекта, согласование с заказчиком) и написание встроенного по (зачастую 80% времени до отгрузки, и потом столько же на стыковку/доработку/устранение ошибок). Ну и не затронуто ОТК, испытания (климатика/вибрации и удары/плесневые грибы и так далее), сдача военпреду если надо, упаковка.
Из моей практики, больше всего времени отнимает составление технического облика изделия (исследовательская работа, проработка различных вариантов решения задачи, защита проекта, согласование с заказчиком) и написание встроенного по (зачастую 80% времени до отгрузки, и потом столько же на стыковку/доработку/устранение ошибок). Ну и не затронуто ОТК, испытания (климатика/вибрации и удары/плесневые грибы и так далее), сдача военпреду если надо, упаковка.
Интересно было бы почитать о тонкостях расположения силовых цепей рядом с сигнальными.
Какими пакетами программ пользоваться?
Не для СВЧ, а чтоб допустим получить точность АЦП 12-14 бит в полосе до 30 кГц рядом с контурами импульсных токов под 100А.
Некоторые разработчики ультразвуковых усилителей мощности по долям пФ подгоняли ёмкости пар проводников относительно друг друга, земли и источников помех. Но на макете, ползая по нему вручную с осциллографом.
Можно ли такое заранее смоделировать, без вдыхания паров припоя?
Ощущение, что слово «цикл» стали употреблять на автомате, не понимая его значения. Цикл на то и цикл, что подразумевает итерации в процессе разработки, а не линейное перечисление этапов. В этом особенная сложность хардварного проекта.
Ммм, но разве в процессе разработки устройства эти «линейные этапы» не повторяются? И внутри тоже, от схемы к элементной базе нужно возвращаться, от платы к схеме, на этапе заказа комплектующих приходится возвращаться или на этапе подгонки под корпус, все очень динамично. Или как тогда логичнее назвать?
Все примерно так и есть, как написано, за исключением одного: разделение проектирования схемы, трассировки PCB, а также (при наличии программируемой элементной базы) программирования HAL на разных людей я считаю крайне порочной практикой, которая снижает эффективность разработки, затягивает время и порождает бюрократию. Дело в том, что эти этапы очень тесно связаны, и для достижения наилучшего результата выполнять их должен один человек, который держит в голове картину целиком, и потому способен производить перекрестные оптимизации в проекте.
Это не мои праздные измышления — я сам разработчик (по вашей классификации — эмбеддер), причем я работал как в компании, которая исповедовала предельное разделение труда, так и в компании, в которой мне предоставляли возможность делать все перечисленные этапы (схемотехника, PCB, HAL) самому — второе для меня гораздо удобнее (собственно, во второй компании я работаю по сей день, прошедшее время — только для красоты предложения).
Будучи единоличным автором схемы и платы, я могу править и то, и другое параллельно. Вижу, что для оптимизации платы требуется изменение в схеме? Сразу правлю схему. Нашел ошибку в схеме, надо поправить плату? Сразу правлю плату. В процессе трассировки выяснилось, что компонент не влезает по геометрии, и надо поменять его? Сразу правлю схему и плату. Это как минимум быстрее, потому что не предполагает никаких занимающих время объяснений и согласований с кем-то еще. Кроме того, чем меньше людей вносило изменения в проект — тем меньше потенциально будет внесено ошибок.
С программистом HAL та же история. Либо это должен быть человек с неплохими знаниями схемотехники (а тогда почему бы ему не проектировать схему самому?), либо разработчик будет вынужден долго и в деталях пояснять, как и каким образом нужно инициализировать оборудование.
Если устройство сложное, лучше разделить его на законченные модули (схема + плата + прошивка), и уже эти модули распределить для разработки между разными людьми.
Так что я бы скорректировал набор специалистов до такого:
1. Разработчик аппаратной части: схема, плата, ПО нижнего уровня.
2. Программист (опционально, если необходимо): прикладной софт (например, под тот же Android).
3. Конструктор механической части: корпус, сборочные чертежи.
4. Менеджер проекта (опционально, если необходимо): беготня с бумажками.
Это в предположении использования контрактного производства.
Это не мои праздные измышления — я сам разработчик (по вашей классификации — эмбеддер), причем я работал как в компании, которая исповедовала предельное разделение труда, так и в компании, в которой мне предоставляли возможность делать все перечисленные этапы (схемотехника, PCB, HAL) самому — второе для меня гораздо удобнее (собственно, во второй компании я работаю по сей день, прошедшее время — только для красоты предложения).
Будучи единоличным автором схемы и платы, я могу править и то, и другое параллельно. Вижу, что для оптимизации платы требуется изменение в схеме? Сразу правлю схему. Нашел ошибку в схеме, надо поправить плату? Сразу правлю плату. В процессе трассировки выяснилось, что компонент не влезает по геометрии, и надо поменять его? Сразу правлю схему и плату. Это как минимум быстрее, потому что не предполагает никаких занимающих время объяснений и согласований с кем-то еще. Кроме того, чем меньше людей вносило изменения в проект — тем меньше потенциально будет внесено ошибок.
С программистом HAL та же история. Либо это должен быть человек с неплохими знаниями схемотехники (а тогда почему бы ему не проектировать схему самому?), либо разработчик будет вынужден долго и в деталях пояснять, как и каким образом нужно инициализировать оборудование.
Если устройство сложное, лучше разделить его на законченные модули (схема + плата + прошивка), и уже эти модули распределить для разработки между разными людьми.
Так что я бы скорректировал набор специалистов до такого:
1. Разработчик аппаратной части: схема, плата, ПО нижнего уровня.
2. Программист (опционально, если необходимо): прикладной софт (например, под тот же Android).
3. Конструктор механической части: корпус, сборочные чертежи.
4. Менеджер проекта (опционально, если необходимо): беготня с бумажками.
Это в предположении использования контрактного производства.
Приветствую. Очень интересно почитать про чужой опыт. В принципе, можно с вами согласиться, это логично все звучит. Если конструктора ПП не очень образованы в электронике, то это действительно может усложнять процесс. НО это все таки применимо в случае, если человек во всех трех направлениях разбирается и если у него есть время.
Например, я работала на фирме только в качестве трассировщика и инженера по документации. У начальника КБ бывали сильные авралы, схему всего немного нужно модернизировать, но времени на перетрассировку нет. Он мог просто распечатать старую, указать что и как поменять, а потом уже просто проверял все ли верно. Равно так же, как был эмбеддер, но он просто разрывался в проекте, потому что много нужно было сделать, а он не успевал по срокам (и то нужно сделать, и это), а на том этапе уже заняло бы много времени вводить в курс нового человека. А если с разработчиком что-то случилось? Весь проект стал мертвым камнем.
Или, например, человек знает схемотехнику, программирование, но посредственный трассировщик, пока он разберется могут поплыть сроки. Кроме того, пока кто-то занимается проектированием, уже можно заниматься программой и алгоритмом, изучением предметной области (если это важно).
Если разделять задачи по компетенциям — это ведет к достижению высокого уровня в своих областях. Но естественно, порой бывает, когда специалисты перестают друг друга понимать и не могут найти точки соприкосновения (особенно, когда говорят об одном и том же, но разными терминами). В этом случае поможет человек, который разбирается в этих всех областях, даже если и не так хорошо — обычно это и есть ведущий проекта, он видит весь проект целиком.
В принципе не сталкивалась с проблемами коммуникации при раздельном проектировании (почти как раздельное питание :D). Некоторые САПР даже имеют специальные для этого функции (контроль версий и жизненного цикла проекта, возможность комментировать прям в проекте).
Очень любопытное обсуждение в тему
Например, я работала на фирме только в качестве трассировщика и инженера по документации. У начальника КБ бывали сильные авралы, схему всего немного нужно модернизировать, но времени на перетрассировку нет. Он мог просто распечатать старую, указать что и как поменять, а потом уже просто проверял все ли верно. Равно так же, как был эмбеддер, но он просто разрывался в проекте, потому что много нужно было сделать, а он не успевал по срокам (и то нужно сделать, и это), а на том этапе уже заняло бы много времени вводить в курс нового человека. А если с разработчиком что-то случилось? Весь проект стал мертвым камнем.
Или, например, человек знает схемотехнику, программирование, но посредственный трассировщик, пока он разберется могут поплыть сроки. Кроме того, пока кто-то занимается проектированием, уже можно заниматься программой и алгоритмом, изучением предметной области (если это важно).
Если разделять задачи по компетенциям — это ведет к достижению высокого уровня в своих областях. Но естественно, порой бывает, когда специалисты перестают друг друга понимать и не могут найти точки соприкосновения (особенно, когда говорят об одном и том же, но разными терминами). В этом случае поможет человек, который разбирается в этих всех областях, даже если и не так хорошо — обычно это и есть ведущий проекта, он видит весь проект целиком.
В принципе не сталкивалась с проблемами коммуникации при раздельном проектировании (почти как раздельное питание :D). Некоторые САПР даже имеют специальные для этого функции (контроль версий и жизненного цикла проекта, возможность комментировать прям в проекте).
Очень любопытное обсуждение в тему
Подскажите пожалуйста, на каком этапе необходимо производить анализ на наличие патентов и их нарушение при производстве изделий?
Если позволите, у меня есть идея сделать аппарат для считывания ЭКГ, ведь здесь запатентовано может быть, что угодно, от самой идеи снимать потенциалы сердца, до наличия на корпусе розовой кнопочки в верхнем правом углу. Приходилось ли сталкиваться с такой проблемой?
Если позволите, у меня есть идея сделать аппарат для считывания ЭКГ, ведь здесь запатентовано может быть, что угодно, от самой идеи снимать потенциалы сердца, до наличия на корпусе розовой кнопочки в верхнем правом углу. Приходилось ли сталкиваться с такой проблемой?
Добрый вечер. Анализ патентов проводится на этапе идеи. Но стоит все таки немного разбираться в видах патентов. Если, например, патент зарегистрирован в каком-то Зимбабве, то Китайцы могут смело передрать все до последней пылинки, потому что патент страны распространяется только на страну. Международные патенты очень дорогие. Патенты на идеи не оформляют.
Устройств ЭКГ безусловно много, если ваш отличается методом обработки или получения сигналов, то этого достаточно, чтобы оформить патент. Иногда патенты вообще оформляют на всякую чушь, главное уметь правильно составить, так называемую, патентную формулу (есть целые учебники, где это объясняется).
Что касается медицинского оборудования, то Вам так же стоит понимать, что сертификация (для мед оборудования она, по-моему, обязательна) очень долгий и трудоемкий процесс. Собственно и разработка мед оборудования требует больших вложений финансовых и временных.
Устройств ЭКГ безусловно много, если ваш отличается методом обработки или получения сигналов, то этого достаточно, чтобы оформить патент. Иногда патенты вообще оформляют на всякую чушь, главное уметь правильно составить, так называемую, патентную формулу (есть целые учебники, где это объясняется).
Что касается медицинского оборудования, то Вам так же стоит понимать, что сертификация (для мед оборудования она, по-моему, обязательна) очень долгий и трудоемкий процесс. Собственно и разработка мед оборудования требует больших вложений финансовых и временных.
UFO just landed and posted this here
Благодарю за совет, статьи этой компании я читала, когда искала материал, чтобы поделиться им со студентами, которые хотят сделать устройство, но не знают как.
Компания пишет о разработке продукта, о самой разработке железа совсем немного. Они во многих вопросах ловко обходят нюансы, которыми делиться, например, не выгодно. Студентам, которые еще не работали над реальными проектами и не видели производства в принципе, эта информация необходима.
Если вы укажите какие моменты неоднозначны, то я с радостью поправлю статью и добавлю объяснения.
Компания пишет о разработке продукта, о самой разработке железа совсем немного. Они во многих вопросах ловко обходят нюансы, которыми делиться, например, не выгодно. Студентам, которые еще не работали над реальными проектами и не видели производства в принципе, эта информация необходима.
Если вы укажите какие моменты неоднозначны, то я с радостью поправлю статью и добавлю объяснения.
Помню позвали меня на собеседование в одну новую окологосударственную фирму. Набирали людей в отдел разработки электроники, и меня собеседовал будущий начальник этого отдела. Он не разбирался в электронике совсем. Он меня расспрашивал, как происходит вообще в принципе процесс проектирования.
Я его спросил, какую задачу нужно выполнить, он мне озвучил довольно сложный проект и довольно сжатые сроки. Ну я ему и рассказал — здесь вам понадобятся:
— Инженер-схемотехник, чтоб разработать схему и плату
— Программист фирмарщик для контроллеров и DSP
— Программист ПЛИС для, соответственно, ПЛИС
— Инженер-конструктор для проектирования корпуса и всякой механики.
Он меня выслушал, и заявляет: «А я думал вообще-то, что это все делает один человек, мы собирались одного нанимать». Я говорю: «При должном усердии вы, конечно, сможете найти такого человека, который в каждой из этих областей будет в нужной степени компетентен. Но сколько вы собираетесь ему платить?» На что он мне ответил: «Ну тысяч восемьдесят, не больше»
Насчет других моментов статьи — сам стал недавно использовать диаграмму Ганта, вещь крайне полезная для оценки сроков, да и вообще для слежения за своим процессом проектирования.
Но вот один момент: разработка новой электроники, принципиально нового устройства — это творчество плюс исследования. Порой оценить сроки очень трудно, т.к. они зависят от огромного количества факторов. Можно неделю думать над реализацией како-то изящного схемотехнического решения, на конечный расчет и отрисовку которого уйдет два часа.
В целом статья была полезна тем, что я понял, что остальной инженерный мир работает так же)
Я его спросил, какую задачу нужно выполнить, он мне озвучил довольно сложный проект и довольно сжатые сроки. Ну я ему и рассказал — здесь вам понадобятся:
— Инженер-схемотехник, чтоб разработать схему и плату
— Программист фирмарщик для контроллеров и DSP
— Программист ПЛИС для, соответственно, ПЛИС
— Инженер-конструктор для проектирования корпуса и всякой механики.
Он меня выслушал, и заявляет: «А я думал вообще-то, что это все делает один человек, мы собирались одного нанимать». Я говорю: «При должном усердии вы, конечно, сможете найти такого человека, который в каждой из этих областей будет в нужной степени компетентен. Но сколько вы собираетесь ему платить?» На что он мне ответил: «Ну тысяч восемьдесят, не больше»
Насчет других моментов статьи — сам стал недавно использовать диаграмму Ганта, вещь крайне полезная для оценки сроков, да и вообще для слежения за своим процессом проектирования.
Но вот один момент: разработка новой электроники, принципиально нового устройства — это творчество плюс исследования. Порой оценить сроки очень трудно, т.к. они зависят от огромного количества факторов. Можно неделю думать над реализацией како-то изящного схемотехнического решения, на конечный расчет и отрисовку которого уйдет два часа.
В целом статья была полезна тем, что я понял, что остальной инженерный мир работает так же)
Четыре уровня профессионализма
- Знаешь, что ничего не знаешь. И это действительно так.
- Уверен, что знаешь всё и "держишь Бога за бороду". Еще называется "звездная болезнь".
- Понимаешь, что действительно ничего не знаешь.
- Убедился, что ничего таки не знаешь, но УЧИТЬСЯ, ОКАЗЫВАЕТСЯ, БОЛЬШЕ НЕ У КОГО!..
Автор: Falconist, 5 сентября, 2016
P.S. уровень 2 имеет время и смелость писать "учебные материалы" со словом "ж*па" :)
Когда ищут человека-оркестра только на само устройство это пол беды. Таких вакансий много.
Но в последнее время стали просить чтоб ещё серверную часть и облако настроили и по совместительству были ещё fullstack вебовскими спецами. И желательно с знанием hi-load — т.к. множество gps треккеров могут совокупно обновлять данные до десятков тыщь раз в секунду если самих треккеров очень много. Да да, планы у всех грандиозные, миллионы экземпляров в год смогут продать того, что такой супер-гений наразрабатывал. Особенно умиляют требования с сантиметровой точности, недели треккинга, размер спичечный коробок и себестоимость в 1000 рублей.
А один модный молодёжный стартап в Мск мне предложил з/п только 50тр т.к. 13 лет опыта разработки железа, публикаций на хабре и красного диплома и курсов MiT, не достаточно — нужны именно научные публикации в ВАКовских журналах вот что главное чтоб комерческие! для иностранных заказчиков! спутники делать и быть резидентом Склоково. Без этого им в гости Путина не приведут и пиарить их видимо не будут.
Извините, наболело т.к. сам в поиске.
добавлено про спутники: а если есть к.т.н. и кошерные публикации, то уже целых аж 70тр, но выше 90 невозможно даже после личной беседы с директором — фонда з/п нет.
т.к. сам в поиске
А приходите к нам, нам сейчас нужно много хороших профессионалов)
спутники делать
А потом они падают, см. Почему земляне делают глючный софт и железо.
Корыстные мотивы разработки и её "углеродный отпечаток" (экологический след) портят карму и производят "баги".
Спасибо за статью. Познавательно.
Но учитывая примечание №1, не плохо было бы дать определение сокращению ПП в начале статьи.
Но учитывая примечание №1, не плохо было бы дать определение сокращению ПП в начале статьи.
Sign up to leave a comment.
Разработка электроники: от идеи до устройства