Автору ролика — нижайший поклон, очень классный ролик
При освоении новой технологии, Hello world — один из самых серьёзных барьеров. С углублением появляются новые трудности, но вот самый первый барьер — он один из «самых непреодолимых», и автор отлично помогает с ним справиться
Ещё раз — огромное спасибо!
Живу в Иерусалиме, а весь hi-tech в Израиле, по существу, сконцентрирован в Центре (Тель-Авив и пр.) Общественный транспорт у нас в глубокой коме, без машины добраться куда-то нереально. И так у всех. Рзультат — каждый день в один конец ок. 2-х часов за рулём, причём половина этого времени — в пробках. Итог — 4 часа в день сэкономить на поездках — плюс, равного которым я представить не могу. Но есть ещё плюсы в удалёнке — можно встать на 2 часа позже (у кого проблемы со сном — оценит), не надо дёргаться из-за зоркого взгляда начальника, можно есть что хочешь и когда хочешь, слушать только свою музыку, работать в тишине, если захочется, а не мучиться из-за соседа по работе, который то ручкой щёлкает, то ставит какую-то тарахтящую дрянь в затычках за 10 долларов, можно посреди дня выйти, прогуляться, вздремнуть, если надо, позвонить заказать очередь к врачу и т.п.
Конечно, есть и минусы — спрос с удалёнщика зачастую выше (мол, если не справился — значит, валял дурака, а не из-за того, что ждал от меня какой-то документ, пока я сидел на заседаниях).
Иногда и вправду проще спросить что-то прямо на месте, иногда просто перекинуться парой слов и т.д.
Но лично я могу найти себе общение, которое вовсе необязательно связано с местом работы
Были и со сменными bed of nails — эти, по-моему, были поновее. А более старые были с несъёмными. Думаю, производители коробок подсуетились в конкурентной борьбе
Многие недоумевают, почему и зачем это делалось. Повторюсь, кроме желания поиграться и покодить, подобная система особенно удобна в производственных условиях, где часто возникают неполадки и необходимо вручную пощупать устройства. Довольно расточительно тратить время на повторяющиеся операции, типа сопоставления имён устройств и соотв. им системных портов. Или ручных загрузок файлов со списками команд для каждого устройства. Если речь идёт об одном компьютере, который стоит у вас на столе, к которому подключены максимум с десяток таких устройств, и ты легко держишь в уме их всех, то да — моя система лишь даёт небольшие преимущества при удалённой работе и возможности запускать Agent хоть на Raspberry, хоть на Windows. Но когда речь заходит о сотне-другой подобных тестовых стендов (стенд — имеется в виду Test Fixture и его индивидуальном компьютере), а на каждом стенде по 5-10 устройств, то при всём желании, запомнить все порты и ассоциированные с ними устройства с их спецификой — это уже слишком. Вот я и строю нечто, что позволит минимизировать подобные неэффективности и даст возможность вносить изменения любому пользователю системы на свой вкус
Верно, и именно этим я воспользовался для того, чтобы автоматически загрузить в интерфейс список предопределённых команд, и связать это устройство с его индивидуальным блоком в интерфейсе. К тому же, у каждого пользователя могут быть свои предпочтения в списке команд, и этим легко управлять — при логине загружается список команд именно того устройства, которое пользователь определил.
Так же легко потом делать шейринг таким спискам.
Там есть возможность записи последовательностей команд (наподобие записи макросов, как были в Visual Studio или в Selenium IDE), их прогонки и пр.
Одним из преимуществ подобной системы (именно для производства) в том, что в неё можно добавить любые фичи «на месте», особенно если они требуются для комнадной работы: скажем, пересылать новичку списки команд в зазипованном файле по мейлу, которые ему потом надо будет импортировать в тот же Docklight или подобные утилиты — не совсем удобно.
Я там планировал добавить возможность логирования всего трафика, бегущего через порты, для последующего анализа. Опять же, в условиях производства, где работают тысячи устройств одновременно, можно начинать обрабатывать подобные массивы данных для поиска всяких проблем. Но и для рядового пользователя/инженера/тестера это просто удобный инструмент для отладки COM-порта на самом «низком» уровне
Как и на любом производстве, особенно если речь идёт о сравнительно небольшой компании, всегда очень остро стоит проблема непрерывности процесса. Т.е., взять тройку ребят и посадить их за долгосрочную разработку — это значит, их надо отрвать от сиюминутных насущных проблем производства (повторюсьм завод не очень большой, ресурсы несколько ограничены, людей взять неоткуда). Кстати, переход на Python, а не, скажем, LabView, позволил подготовиться к движению в любом направлении (Python-аппликации во многих случаях очень легко переводятся с одной платформы на другую).
Скажем, одной из таких проблем была необходимость гарантировать рабочие драйвера для всего зоопарка устройств, с которыми работали. Проблемы легаси, отсутствие унификации многих схем и процессов создавали серьёзные препятствия для быстрой и безболезненной миграции с одной схемы на другую
Да, конечно, я не спорю, что для отдельного разработчика вполне сойдёт и терминал — кому что удобнее. Но когда речь идёт о производственной линии, возникает необходимость в удобной графической оболочке, с централизованным и унифицированным доступом и возможностью заточить любую функцию под цех/линию/компанию. Особенно, в случае, если часто возникает необходимость в частом ручном повторении рутинных операций, которые так и «напрашиваются» на автоматизацию.
Если честно, на всех подобных устройствах был распаян, если я не ошибаюсь, cp2102 USB UART adapter, и в него можно было с помощью фирменной утилитки прошить имя устройства (любую произвольную строку). Я в меньшей степени электронщик, я больше программированием занимаюсь. Так вот, под python есть библиотечка infini что-то там, позволяет читать registry в windows, оттуда и сопоставляем имя порта (скажем, COM13), и название устройства (например, PowerSupply1). А в Linux и того проще, там в б-ке pyserial есть метод get_usb_description. И это было супер удобно
В подобной конфигурации ноутбук неудобен и громоздок. Нет нужды в клавиатуре и экране. Там нужен просто несложный компьютер, к которому через USB подключаются все наши устройства, а через сеть с этим компом можно ими управлять. Raspberry там был бы идеален, но начальник побаивался переводить всю инфраструктуру на Linux
Правильно :) Ведь это всего-лишь демо.
Правда, моделей пока что ок. 20-ти, и, опять же, был бы рад идеям (ну, или назовём это feature-request).
Кстати, попользуйтесь, может, увидите в этом некое удобство, заодно и сможете подкинуть пару идей ;)
Опять же, будет интерес у публики — допилю, доведу до ума хотя бы внешний вид
Всё верно, но нам была необходима именно удобная для не-специалиста, не-разработчика, система, с простым и удобным интерфейсом. Вы правы, она несколько громоздка, но глядя назад, я очень хорошо понимаю, что лишнего в ней нет.
Может, я выразился несколько смазанно.
Типичная ситуация: к одному компу, ассоциированному (физически и логически) с конкретным Test Fixture, присоединены несколько устр-в (в т.ч. и тестируемое устр-во, DUT — device under test). Скажем, одно из вспомогательных устройств — просто генератор RF. Шлём ему команду «излучи чего-то там на 835 МГц». Он отвечает «ОК». При этом я хочу одновременно видеть реакцию моего DUT, что он действительно принял этот сигнал. И желательно, чтобы мне не приходилось каждый раз определять, на каком порту сидит мой генератор, а на каком — DUT. Система должна сама об этом позаботиться. И автоматически загрузить список команд для каждого типа устройства. И желательно, чтобы всё это интегрировалось в общую систему тестирования, интерфейс которой оформлен через Web. Ну, и там ещё всякие мелочи.
Просто честно: удобство и эргономика в производстве очень часто имеет свой денежный эквивалент. Удобный стул для пайщицы или качественный монитор для программера — это не роскошь, а средство увеличения эффективности труда. Где-то подобными соображениями я и руководствовался
С радостью.
Сами коробки на заводе не делались — они заказывались у сторонних производителей (тот же Ingun).
Вспомогательное оборудование — речь обо всяких программируемых источниках питания (небольшие одноплатные устр-ва с переходником usb-uart), платы с реле (switchboard), всякие штуковины для работы с радиосигналами (анализаторы спектра, снифферы и пр.) Все устр-ва, как я писал, имели стандартный интерфейс — COM-port, и было решено писать весь софт на Python. Удобства более чем очевидны, для понимания работы самих устройств знать не надо было практически ничего, был список команд, которые каждое устр-во понимает, через pyserial отправлялась команда, параллельно вычитывалась реакция устр-ва.
Далее ход тестов, составленный отделом разработки, реализовывался всё на том же Python, а интерфейс к самой коробке был реализован как небольшой web-server, у которого был GUI для оператора, и API для центральной системы, которая все эти тесты гоняла. В итоге получалась очень гибкая, удобная и легко масштабируемая система. Но, как я и сказал, для ручной отладки и оперативного исправления всяких неисправностей очень не хватало подобного COM-port монитора.
Не знаю, насколько это может быть актуально, но я тут одну систему строю, она позволяет через web «общаться» с устройствами через UART. Я немного подзабросил разработку ввиду слабого интереса общественности, но если будут заинтересованные люди — связывайтесь.
Если интересно взглянуть на демо:
Совершенно дурацкая мысль, но подумал вот о чём: ставим подобное устройство в комнате, в ней же ставим блюдце с небольшим кол-вом спирта (или чего-то подобного, что при горении выделяет ЦО2) или даже лучше спиртовку (так безопаснее). Поджигаем, закрываем дверь снаружи (чтобы дыхание наблюдателя не сильно влияло на концентрацию ЦО2 в комнате), а потом смотрим на замеры прибора. Если кол-во спирта известно, и он достаточно чистый (в аптеке 96% продаётся), то можно очень точно подсчитать кол-во выделившегося ЦО2 (элемнтарная химия). Возможно, так удалось бы откалибровать шкалу (насколько верно изменяется ритм повышения ЦО2 в воздухе), но, увы, не ноль (наверное, химики могут подсказать надёжный и действенный способ очищения воздуха от ЦО2)
Очень классный ресурс, вообще, с языками не особо поладил, но, с другой стороны, за 20 с лишком лет, прожив вне СНГ, не особо жалую русскоязычный сегмент инета, но хабра — классный ресурс: и по содержанию, и по стилю, и по контингенту (всё познаётся в сравнении). Желаю удачи Ресурсу, по-моему, у вас есть всё, необходимое для успеха.
Вообще, как мен кажется, чтобы не создавать чувства отчуждённости у пользователей, не владеющих русским, которые будут видеть, что русскоязычные статьи активно просматриваются и обсуждаются, то, как минимум, для более лёгкой их интеграции, имеет смысл добавить автоматический перевод в любую сторону (En=>Ru, Ru=>En), подобно тому, как это сегодян в Фейсбуке, допустим., в т.ч., и в комментариях.
С другой стороны, если кто-то попытается добавить коммент на английском, то могут быть недоброжелательно настроенные «местные», которые заклюют такого незадачливого англосакса (мол, вали в свои американские Интернеты). Такое надо мониторить внимательно, дабы не отпугнуть английский сегмент.
Короче, ребята, кучу успехов, обязательно порекомендую вас своим нерусскоязычным друзьям :)
При освоении новой технологии, Hello world — один из самых серьёзных барьеров. С углублением появляются новые трудности, но вот самый первый барьер — он один из «самых непреодолимых», и автор отлично помогает с ним справиться
Ещё раз — огромное спасибо!
Здорово помогло. Спасибо!
www.bzflag.org
Конечно, есть и минусы — спрос с удалёнщика зачастую выше (мол, если не справился — значит, валял дурака, а не из-за того, что ждал от меня какой-то документ, пока я сидел на заседаниях).
Иногда и вправду проще спросить что-то прямо на месте, иногда просто перекинуться парой слов и т.д.
Но лично я могу найти себе общение, которое вовсе необязательно связано с местом работы
Так же легко потом делать шейринг таким спискам.
Там есть возможность записи последовательностей команд (наподобие записи макросов, как были в Visual Studio или в Selenium IDE), их прогонки и пр.
Одним из преимуществ подобной системы (именно для производства) в том, что в неё можно добавить любые фичи «на месте», особенно если они требуются для комнадной работы: скажем, пересылать новичку списки команд в зазипованном файле по мейлу, которые ему потом надо будет импортировать в тот же Docklight или подобные утилиты — не совсем удобно.
Я там планировал добавить возможность логирования всего трафика, бегущего через порты, для последующего анализа. Опять же, в условиях производства, где работают тысячи устройств одновременно, можно начинать обрабатывать подобные массивы данных для поиска всяких проблем. Но и для рядового пользователя/инженера/тестера это просто удобный инструмент для отладки COM-порта на самом «низком» уровне
Скажем, одной из таких проблем была необходимость гарантировать рабочие драйвера для всего зоопарка устройств, с которыми работали. Проблемы легаси, отсутствие унификации многих схем и процессов создавали серьёзные препятствия для быстрой и безболезненной миграции с одной схемы на другую
Если честно, на всех подобных устройствах был распаян, если я не ошибаюсь, cp2102 USB UART adapter, и в него можно было с помощью фирменной утилитки прошить имя устройства (любую произвольную строку). Я в меньшей степени электронщик, я больше программированием занимаюсь. Так вот, под python есть библиотечка infini что-то там, позволяет читать registry в windows, оттуда и сопоставляем имя порта (скажем, COM13), и название устройства (например, PowerSupply1). А в Linux и того проще, там в б-ке pyserial есть метод get_usb_description. И это было супер удобно
В подобной конфигурации ноутбук неудобен и громоздок. Нет нужды в клавиатуре и экране. Там нужен просто несложный компьютер, к которому через USB подключаются все наши устройства, а через сеть с этим компом можно ими управлять. Raspberry там был бы идеален, но начальник побаивался переводить всю инфраструктуру на Linux
Правда, моделей пока что ок. 20-ти, и, опять же, был бы рад идеям (ну, или назовём это feature-request).
Кстати, попользуйтесь, может, увидите в этом некое удобство, заодно и сможете подкинуть пару идей ;)
Опять же, будет интерес у публики — допилю, доведу до ума хотя бы внешний вид
Типичная ситуация: к одному компу, ассоциированному (физически и логически) с конкретным Test Fixture, присоединены несколько устр-в (в т.ч. и тестируемое устр-во, DUT — device under test). Скажем, одно из вспомогательных устройств — просто генератор RF. Шлём ему команду «излучи чего-то там на 835 МГц». Он отвечает «ОК». При этом я хочу одновременно видеть реакцию моего DUT, что он действительно принял этот сигнал. И желательно, чтобы мне не приходилось каждый раз определять, на каком порту сидит мой генератор, а на каком — DUT. Система должна сама об этом позаботиться. И автоматически загрузить список команд для каждого типа устройства. И желательно, чтобы всё это интегрировалось в общую систему тестирования, интерфейс которой оформлен через Web. Ну, и там ещё всякие мелочи.
Просто честно: удобство и эргономика в производстве очень часто имеет свой денежный эквивалент. Удобный стул для пайщицы или качественный монитор для программера — это не роскошь, а средство увеличения эффективности труда. Где-то подобными соображениями я и руководствовался
Сами коробки на заводе не делались — они заказывались у сторонних производителей (тот же Ingun).
Вспомогательное оборудование — речь обо всяких программируемых источниках питания (небольшие одноплатные устр-ва с переходником usb-uart), платы с реле (switchboard), всякие штуковины для работы с радиосигналами (анализаторы спектра, снифферы и пр.) Все устр-ва, как я писал, имели стандартный интерфейс — COM-port, и было решено писать весь софт на Python. Удобства более чем очевидны, для понимания работы самих устройств знать не надо было практически ничего, был список команд, которые каждое устр-во понимает, через pyserial отправлялась команда, параллельно вычитывалась реакция устр-ва.
Далее ход тестов, составленный отделом разработки, реализовывался всё на том же Python, а интерфейс к самой коробке был реализован как небольшой web-server, у которого был GUI для оператора, и API для центральной системы, которая все эти тесты гоняла. В итоге получалась очень гибкая, удобная и легко масштабируемая система. Но, как я и сказал, для ручной отладки и оперативного исправления всяких неисправностей очень не хватало подобного COM-port монитора.
Если интересно взглянуть на демо:
18.224.10.61
username: operator_0
password: 123456789
Выбрать QA_Test и потом station_0
Вообще, как мен кажется, чтобы не создавать чувства отчуждённости у пользователей, не владеющих русским, которые будут видеть, что русскоязычные статьи активно просматриваются и обсуждаются, то, как минимум, для более лёгкой их интеграции, имеет смысл добавить автоматический перевод в любую сторону (En=>Ru, Ru=>En), подобно тому, как это сегодян в Фейсбуке, допустим., в т.ч., и в комментариях.
С другой стороны, если кто-то попытается добавить коммент на английском, то могут быть недоброжелательно настроенные «местные», которые заклюют такого незадачливого англосакса (мол, вали в свои американские Интернеты). Такое надо мониторить внимательно, дабы не отпугнуть английский сегмент.
Короче, ребята, кучу успехов, обязательно порекомендую вас своим нерусскоязычным друзьям :)