Постоянно читаю в инете о том, как человечество деградировало в плане строительства. И, в качестве примера, тут же показывают пару фоток - какой-нибудь старинный дом с колоннами и скульптурами и современную панельку.
Я в строительстве примерно вообще не разбираюсь (кроме электрокоммуникаций). Но немножко понимаю в UI/UX. А вот один из ближайших коллег - как раз архитектор.
Так вот. Во-первых сложно утверждать о деградации, сравнивая штучную постройку (считай luxury), которую себе строил какой-нибудь граф или купец первой гильдии, с массовым застроем, в котором живут простолюдины. Знаете, как жили простолюдины в 14 веке? Смотрите слайд (причем это после реставрации современными мастерами). Теперь сравните с панелькой или даже хрущевкой, и прикиньте кто куда деградировал. И это еще мы не учитываем, что до наших времен дожили самые красивые дома из прошлого. Некрасивые - сносились.
Но колонны и статуи не строят? Да почему не строят. Строят, luxury на то и luxury, что строишь что хочешь. Галкин себе построил замок со скульптурами. Хью Хефнер - тоже любил косить под замки. Кто-то строит дом-аэропорт, как Траволта, а кто-то дом-Луна-парк, как Майкл Джексон.
Но общий тренд в luxury - минимализм и большие панорамные окна. Потому что могут себе позволить. Раньше панорамных окон не было, поэтому лепили маленькие и колонны. А теперь влепишь колонну - не будет панорамы. И конюшня не нужна - лучше гараж. Но если сильно хотите - влепите колонну, любой каприз за ваши деньги. И конюшню тоже пристройте, если любите лошадей. Это про UX.
А причем тут UI? Требвания, как сейчас, так и 500 лет назад - дом должен быть аккуратным и похож снаружи на дом. Современные материалы позволяют делать дома ультра-минималистического дизайна, где одно стекло и тонкие вертикальные несущие конструкции. Но если посторонний человек с первого взгляда скажет, что это - дом, а не амбар или склад, значит задача дизайнера выполнена на отлично.
Я в строительстве примерно вообще не разбираюсь (кроме электрокоммуникаций). Но немножко понимаю в UI/UX. А вот один из ближайших коллег - как раз архитектор.
Так вот. Во-первых сложно утверждать о деградации, сравнивая штучную постройку (считай luxury), которую себе строил какой-нибудь граф или купец первой гильдии, с массовым застроем, в котором живут простолюдины. Знаете, как жили простолюдины в 14 веке? Смотрите слайд (причем это после реставрации современными мастерами). Теперь сравните с панелькой или даже хрущевкой, и прикиньте кто куда деградировал. И это еще мы не учитываем, что до наших времен дожили самые красивые дома из прошлого. Некрасивые - сносились.
Но колонны и статуи не строят? Да почему не строят. Строят, luxury на то и luxury, что строишь что хочешь. Галкин себе построил замок со скульптурами. Хью Хефнер - тоже любил косить под замки. Кто-то строит дом-аэропорт, как Траволта, а кто-то дом-Луна-парк, как Майкл Джексон.
Но общий тренд в luxury - минимализм и большие панорамные окна. Потому что могут себе позволить. Раньше панорамных окон не было, поэтому лепили маленькие и колонны. А теперь влепишь колонну - не будет панорамы. И конюшня не нужна - лучше гараж. Но если сильно хотите - влепите колонну, любой каприз за ваши деньги. И конюшню тоже пристройте, если любите лошадей. Это про UX.
А причем тут UI? Требвания, как сейчас, так и 500 лет назад - дом должен быть аккуратным и похож снаружи на дом. Современные материалы позволяют делать дома ультра-минималистического дизайна, где одно стекло и тонкие вертикальные несущие конструкции. Но если посторонний человек с первого взгляда скажет, что это - дом, а не амбар или склад, значит задача дизайнера выполнена на отлично.
👍27💩2
Поскольку под Шиндовс тоже прходится что-то делать, я всегда вспоминаю одного коллегу, с которым посчастливилость работать лет 20 назад в одной команде.
Коллега был профессиональный Шиндовс-админ (как тогда это называлось), имел кучу сертификатов от MS, был очень позитивный человек и постоянно со всех смеялся. Он смеялся с нас, ковырявших RedHat (еще до-RHEL-ный). Смеялся с инженеров Microsoft, которые сами не понимали, что суппортят. Смеялся с их доков, где на каждую вторую проблему был один солюшн - repair-reinstall, чиня упавшие IIS и SQL Server какими-то страшными методами, которые изобретал сам.
В итоге коллега в середине нулевых дернул куда-то в Майами, в какой-то большой ентерпрайз, заработал себе на домик у моря и где-то там счастливо сгинул, жутко разбогатев и уйдя из IT-тусовки.
Его философия всегда была простой - внутри Шиндовс, и того, 20-летней давности, и современного - та самая NT и большинство своих технологий она тащит еще с NT4. А разве NT4 была плохой ОС на своё время? Вот. И не обращайте внимания, что там опять навертели для юзеров их сумасшедшие UX и какую очередную малварь врубили из коробки. Любить шиндовс, как десктопную ОС у себя дома и любить шиндовс, как дойную корову - две большие разницы.
К сожалению, у меня так не получается. Но надо себя заставлять.
Коллега был профессиональный Шиндовс-админ (как тогда это называлось), имел кучу сертификатов от MS, был очень позитивный человек и постоянно со всех смеялся. Он смеялся с нас, ковырявших RedHat (еще до-RHEL-ный). Смеялся с инженеров Microsoft, которые сами не понимали, что суппортят. Смеялся с их доков, где на каждую вторую проблему был один солюшн - repair-reinstall, чиня упавшие IIS и SQL Server какими-то страшными методами, которые изобретал сам.
В итоге коллега в середине нулевых дернул куда-то в Майами, в какой-то большой ентерпрайз, заработал себе на домик у моря и где-то там счастливо сгинул, жутко разбогатев и уйдя из IT-тусовки.
Его философия всегда была простой - внутри Шиндовс, и того, 20-летней давности, и современного - та самая NT и большинство своих технологий она тащит еще с NT4. А разве NT4 была плохой ОС на своё время? Вот. И не обращайте внимания, что там опять навертели для юзеров их сумасшедшие UX и какую очередную малварь врубили из коробки. Любить шиндовс, как десктопную ОС у себя дома и любить шиндовс, как дойную корову - две большие разницы.
К сожалению, у меня так не получается. Но надо себя заставлять.
👍22💩1
Шиндовс сервер 2022 оказался приличным. Апдейты автоматом не ставятся, можно удалить дефендер.
Надо сделать сначала плохо, а потом как было и все довольны.
Надо сделать сначала плохо, а потом как было и все довольны.
😁26🔥6
Думаю все уже слышали цитату из интервью: "на Rust написано 35 движков игр и 5 игр". Причина в том, что Rust - слишком мощный инструмент, бьющий по перфекционизму тех, кто и так к нему склонен (тоесть примерно каждый первый системный программер).
И там, где вы целый вечер думаете как обойти immutable, расставляете лайфтаймы и оттачиваете идеальный код, крестовик (даже не потому что он глупый, а от греха) сделает clone, пушнет в прод и пойдет пить пиво. Раст же позволяет писать идеальный код безопасно. Но долго.
Догма о том, что "я сегодня потрачу вечер, но в будущем подобный код напишу намного быстрее" - ошибочна. Это будущее не наступит примерно никогда.
Поэтому включайте здравый смысл и пользуйтесь принципом Парето. 20% говнокода в проекте - это нормально. _Особенно_ те участки, которые никак не влияют на производительность и безопасность.
И там, где вы целый вечер думаете как обойти immutable, расставляете лайфтаймы и оттачиваете идеальный код, крестовик (даже не потому что он глупый, а от греха) сделает clone, пушнет в прод и пойдет пить пиво. Раст же позволяет писать идеальный код безопасно. Но долго.
Догма о том, что "я сегодня потрачу вечер, но в будущем подобный код напишу намного быстрее" - ошибочна. Это будущее не наступит примерно никогда.
Поэтому включайте здравый смысл и пользуйтесь принципом Парето. 20% говнокода в проекте - это нормально. _Особенно_ те участки, которые никак не влияют на производительность и безопасность.
👍29😁6
В филдбас-протоколах обычно используется pull (когда один участник сети тянет данные с другого), реже - push (когда другой сам сообщает данные первому), но возможно вы удивитесь, что этот push - часто на самом деле не push, a тоже pull. Или, как я его называю, server pull.
Вкратце, что это такое - после подключения к серверу вы не подписываетесь на топик или тип события, как в стандартных Pub/Sub моделях, а ставите серверу задачу гонять pull-цикл у себя с заданой вами частотой, а вам пушать данные (всё время или только при изменениях). Когда вы отключаете соединение - задача снимается. Именно так работает push в OPC или в TwinCAT ADS. Server pull позволяет, в первую очередь, экономить ресурсы сети, которая в fieldbus может быть весьма медленной.
Почему нельзя, чтобы сервер просто подписал вас на события и кидал вам какие-то данные, когда они приходят? Ответ нужно искать немножко в историю и немножко вглубь - там, где сервер оперирует напрямую с DIN/AIN, где никаких событий нету (особенно на AIN), а данные есть всегда. И эти данные семплируются со входа с какой-то фиксированной частотой. Которую фактически задаете вы, как клиент, устанавливая серверу задачу семплировать физический вход.
Прошли года, появилось 100500 абстракций, между SCADA и аналоговым входом могут висеть десятки приложений, но протоколы изменяться не спешат - даже если сервер получает уже цифровые данные в виде событий, клиент всё равно устанавливает на эти события семплирование с фиксированной частотой.
Почему этот подход до сих пор жив и успешно применяется, во времена, когда у нас есть MQTT и прочие достижения IoT? Ответов несколько, но они все простые.
- Унификация. Понятно что между веб-браузером и веб-HMI никакого server pull не бывает - там уже веб-сокет и события. Но веб-HMI крутится на сервере, который может опрашивать разные пиры по одним и тем же протоколам и ему не важно знать, семплирование входов там или цифровые события. Потом уже веб-сервер конвертит всё это в вебсокет-события, но это уже другая история.
- Более простая и понятная логика работы с контекстом. В случае MQTT, или скажем Kafka, у нас есть четкие топики, в которых данные рассылаются всем подписавшимся. В случае же работы с филдбас-контекстом, у нас могут быть сложные структуры, массивы или фильтры. Этому подавай весь VARIABLE, тому - VARIABLE[0] IF VARIABLE[0]>100, а этому - VARIABLE[5-100]. Если бы мы работали по событиям - бремя разборки, кому что нужно, ложилось бы на pub и соседние воркеры, со всеми вытекающими сложностями и датарейсами. В случае же server pull - у сервера есть простой конкретный воркер, который занимается, скажем, конкретно VARIABLE[5-100], опрашивает ее 50 раз в секунду и пушает конкретному клиенту ее изменения.
- Фильтрация событий. В физическом мире редко бывают события, которые мгновенно появляются и исчезают - нагрузка в амперах повышается в течение микросекунд, даже в случае КЗ. А, скажем, температура, растет в пределах секунд, а то и десятков. И если одно устройство изволит семплировать вход, скажем с частотой 1000Hz - это совершенно не значит, что всем участникам системы нужна именно такая частота для сбора данных. Иногда она может быть даже вредной. Хотя самому устройству она и полезна - пакетник (представим себе его цифровым) должен вырубить цепь как только произошло КЗ, но TSDB, а тем более оператору, совершенно необязательно знать, как именно там росла нагрузка.
Вкратце, что это такое - после подключения к серверу вы не подписываетесь на топик или тип события, как в стандартных Pub/Sub моделях, а ставите серверу задачу гонять pull-цикл у себя с заданой вами частотой, а вам пушать данные (всё время или только при изменениях). Когда вы отключаете соединение - задача снимается. Именно так работает push в OPC или в TwinCAT ADS. Server pull позволяет, в первую очередь, экономить ресурсы сети, которая в fieldbus может быть весьма медленной.
Почему нельзя, чтобы сервер просто подписал вас на события и кидал вам какие-то данные, когда они приходят? Ответ нужно искать немножко в историю и немножко вглубь - там, где сервер оперирует напрямую с DIN/AIN, где никаких событий нету (особенно на AIN), а данные есть всегда. И эти данные семплируются со входа с какой-то фиксированной частотой. Которую фактически задаете вы, как клиент, устанавливая серверу задачу семплировать физический вход.
Прошли года, появилось 100500 абстракций, между SCADA и аналоговым входом могут висеть десятки приложений, но протоколы изменяться не спешат - даже если сервер получает уже цифровые данные в виде событий, клиент всё равно устанавливает на эти события семплирование с фиксированной частотой.
Почему этот подход до сих пор жив и успешно применяется, во времена, когда у нас есть MQTT и прочие достижения IoT? Ответов несколько, но они все простые.
- Унификация. Понятно что между веб-браузером и веб-HMI никакого server pull не бывает - там уже веб-сокет и события. Но веб-HMI крутится на сервере, который может опрашивать разные пиры по одним и тем же протоколам и ему не важно знать, семплирование входов там или цифровые события. Потом уже веб-сервер конвертит всё это в вебсокет-события, но это уже другая история.
- Более простая и понятная логика работы с контекстом. В случае MQTT, или скажем Kafka, у нас есть четкие топики, в которых данные рассылаются всем подписавшимся. В случае же работы с филдбас-контекстом, у нас могут быть сложные структуры, массивы или фильтры. Этому подавай весь VARIABLE, тому - VARIABLE[0] IF VARIABLE[0]>100, а этому - VARIABLE[5-100]. Если бы мы работали по событиям - бремя разборки, кому что нужно, ложилось бы на pub и соседние воркеры, со всеми вытекающими сложностями и датарейсами. В случае же server pull - у сервера есть простой конкретный воркер, который занимается, скажем, конкретно VARIABLE[5-100], опрашивает ее 50 раз в секунду и пушает конкретному клиенту ее изменения.
- Фильтрация событий. В физическом мире редко бывают события, которые мгновенно появляются и исчезают - нагрузка в амперах повышается в течение микросекунд, даже в случае КЗ. А, скажем, температура, растет в пределах секунд, а то и десятков. И если одно устройство изволит семплировать вход, скажем с частотой 1000Hz - это совершенно не значит, что всем участникам системы нужна именно такая частота для сбора данных. Иногда она может быть даже вредной. Хотя самому устройству она и полезна - пакетник (представим себе его цифровым) должен вырубить цепь как только произошло КЗ, но TSDB, а тем более оператору, совершенно необязательно знать, как именно там росла нагрузка.
👍16🔥3
Типичная ситуация:
1) написал огромный модуль и он сразу же работает
2) умышленно суешь туда пару багов, чтобы убедиться, что тебя не обманывают
1) написал огромный модуль и он сразу же работает
2) умышленно суешь туда пару багов, чтобы убедиться, что тебя не обманывают
😁37👍6👎3🔥2💩2
Я решил собрать все моки, на которых мы тестируем PLC, SCADAs и прочее, в один пакет, который ставится как расширение к EVA ICS v4.
https://info.bma.ai/en/actual/sim/index.html
Пока там только Modbus (TCP/RTU), чуть позже добавлю OPC UA и, возможно, ADS (он у нас, как и у всех, слегка кривой). В отличие от аналогов, наш Virtual Fieldbus Simulator полностью опен-сорц. По уже сложившейся традиции, Modbus-датчики могут использовать как источник данных Matlab Simulink (с той же или другой машины). Есть также компонент реле, который эмулирует релейки на 8 портов на coil 0-7 или как биты h0 (переключается в конфиге).
Через основное API также можно выводить состояние отдельных эмулируемых компонентов на дашборды, например в ту же графану.
p.s. aarch64 поддерживается, а значит можно эмулировать прямо внутри embedded PLCs с линухом, цепляя virtual Modbus на реальный Serial но с гирляндой виртуальных устройств за ним (чем сейчас и занимаюсь).
https://info.bma.ai/en/actual/sim/index.html
Пока там только Modbus (TCP/RTU), чуть позже добавлю OPC UA и, возможно, ADS (он у нас, как и у всех, слегка кривой). В отличие от аналогов, наш Virtual Fieldbus Simulator полностью опен-сорц. По уже сложившейся традиции, Modbus-датчики могут использовать как источник данных Matlab Simulink (с той же или другой машины). Есть также компонент реле, который эмулирует релейки на 8 портов на coil 0-7 или как биты h0 (переключается в конфиге).
Через основное API также можно выводить состояние отдельных эмулируемых компонентов на дашборды, например в ту же графану.
p.s. aarch64 поддерживается, а значит можно эмулировать прямо внутри embedded PLCs с линухом, цепляя virtual Modbus на реальный Serial но с гирляндой виртуальных устройств за ним (чем сейчас и занимаюсь).
🔥8👍5
Сегодня приехал контроллер с парой RS485. Не поверите, впервые в жизни не прозванивал тестерами, а взял инструкцию прочитать, какой из них куда мапится в системе.
Старею.
Старею.
😁20👍5👎1🔥1
Как изменился IIoT за последние 5 лет
2018: Там внутри Raspberry Pi? Мы это не поставим
2023: Там внутри Raspberry Pi? Отлично, хорошо что не какой-то нонейм-клон
2018: Node-RED для логики? Вы шутите?
2023: Node-RED для логики? Отлично, он такой классный!
2018: Linux? Он же не hard-realtime!
2023: - Linux!
- Он же не hard-realtime?
- Похуй! Вон у Siemens тоже всё уже на Linux.
2018: Там внутри Raspberry Pi? Мы это не поставим
2023: Там внутри Raspberry Pi? Отлично, хорошо что не какой-то нонейм-клон
2018: Node-RED для логики? Вы шутите?
2023: Node-RED для логики? Отлично, он такой классный!
2018: Linux? Он же не hard-realtime!
2023: - Linux!
- Он же не hard-realtime?
- Похуй! Вон у Siemens тоже всё уже на Linux.
😁18🔥13👍2
''Controlling a laser with Linux is crazy, but everyone in this room is crazy in his own way. So if you want to use Linux to control an industrial welding laser, I have no problem with your using Preempt RT''
Linus Torvalds at Kernel Summit 2006
Linus Torvalds at Kernel Summit 2006
👍14🔥3
Почему я не люблю облака. Сегодня
- почему не работает?
- проблема в облаке
- почини облако
- как я починю облако?
- а что я починить должен? тыжпрограммист. почини облако!
here we go again
- почему не работает?
- проблема в облаке
- почини облако
- как я починю облако?
- а что я починить должен? тыжпрограммист. почини облако!
here we go again
😁35👍8
Вопрос от джуна сегодня:
- почему вы говорите "запушай в мастер", если главная ветка main?
Вот и выросло поколение...
- почему вы говорите "запушай в мастер", если главная ветка main?
Вот и выросло поколение...
😁61👍18
В написании симулятора серверной части TwinCAT ADS, главное - не написать его лучше, чем у производителя.
Написал, что можно запросить массив как [index-] или [-index]. На тестах оказалось, что настоящий TwinCAT 3 так не умеет. Пришлось выкинуть.
Зато ADS позволяет запросить масссив как [start-end] при условии, что start > end (например array[1-0]). При этом обязана вернуться переменная, которая будет работать как настоящая, но её размер будет 0. Я такое запрещал, пришлось дописать.
Кстати, как оказалось, хваленая TwinCAT/BSD имеет очень restricted ADS. По сути работает только Read state и Device info. Ни читать, ни писать, ни даже получить список переменных вы не можете. Позор.
Написал, что можно запросить массив как [index-] или [-index]. На тестах оказалось, что настоящий TwinCAT 3 так не умеет. Пришлось выкинуть.
Зато ADS позволяет запросить масссив как [start-end] при условии, что start > end (например array[1-0]). При этом обязана вернуться переменная, которая будет работать как настоящая, но её размер будет 0. Я такое запрещал, пришлось дописать.
Кстати, как оказалось, хваленая TwinCAT/BSD имеет очень restricted ADS. По сути работает только Read state и Device info. Ни читать, ни писать, ни даже получить список переменных вы не можете. Позор.
😁15👍4
У меня такими темпами на канале скоро будет 1000 подписчиков, всем спасибо, кто читает. Спасибо и тем, кто не читает а просто висит для количества, мне всё равно приятно.
В связи с этим, если вдруг появится реклама - это не я, это всё Паша Дуров.
В связи с этим, если вдруг появится реклама - это не я, это всё Паша Дуров.
👍32🔥11😁8