Наконец накупил Wago 2002 как дурак фантиков и наслаждаюсь. На слайде играюсь с нашим Virtual Fieldbus Simulator в смешанном режиме - хардварный RS485 с Modbus RTU master (оранжевый=А, серый=В), дальше U1= хардварная релейка, а U3,4,5 - виртуальная релейка и два датчика.

Работает на отлично, master считает, что вся шина реальная.

p.s. кто из Чехии - Wago самый большой ассортимент в EMAS. В K&V тухло.

И лайфхак, как сделать удобный многоэтажный DIN-стенд для лаборатории.

Вот это одноэтажное говно стоит в среднем 20-25€, вы его не покупайте. А покупайте хороший диджейский стенд (начинается от 15€), который честно выдержит вам пару кило оборудования.

Напоминаю, что музыкальное оборудование полностью совместимо по размерам с серверным. Метр DIN-рейки стоит 2-3€, распилить ее на пару кусков по 19" - 5 минут ручной ножовкой. А болты и гайки М6 у вас конечно есть, вы же из IT, или как?

- спрашивать программиста на собеседовании, что такое SOLID, это все равно, что спрашивать электрика на собеседовании законы Кирхгофа
- совсем не тоже самое. электрик может и в бубен дать

Я когда говорил, что экосистема Rust толкает ко всяким вредным привычкам (в частности, не использовать пулы тасков) - я не шутил.

Подробно разбирали со студентами Tokio Tutorial. Раздел Spawning https://tokio.rs/tokio/tutorial/spawning - и сразу типичный антипаттерн, взять TcpStream с listener'a и сделать прямой spawn на обработку. Сколько проживёт такой сервер? Известно сколько - пока продюсеры (клиенты) не начнут обгонять консьюмеров, дальше будет уверенная дорога в дивный мир out of memory. Тоже самое в разделах Shared State и I/O.

Но это примеры для новичков, дальше, наверное, будет правильно? Нет, не будет. Дальше примеров нет.

Существует ли готовый Tokio Task Pool, чтобы хотя бы банально ограничивать количество тасков семафорами? Я не нашел. Пора свой выковырять и залить, наверное.

Мне, как любителю AI, интересна тема и генерации контента в интеллекте природном, а именно - сноведений.

Есть такой прикол, что вы просыпаетесь, когда умираете во сне. Сомнология объясняет это тем, что ваш мозг не знает, что будет после смерти.

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

Причем, что интересно для интеллекта природного, сколько бы вы роликов про прыжки не посмотрели - это не работает.

Уже и личку штурмуют. Накачают своих пираток, а потом с борроу чекером ебутся

На 1 сентября детям и родителям предложили придумать слоган школы.

Наивный квест, как для 2023 года. Вы же понимаете, кто победил?

Зарелизил Virtual Fieldbus Simulator 1.0.1. Напомню, это набор сервисов, которые ставятся пакетом на EVA ICS v4 и могут эмулировать реальный филдбас так, что внешнее железо-софт ничего не замечает и можно легко поднять среду разработки или гонять тесты из CI/CD.

В обновление вошел симулятор ADS из TwinCAT 3. На данный момент это самая полная реализация ADS/AMS over TCP на рынке (кроме, естественно, родной от Beckhoff)

Также Virtual Modbus был протестирован несколько раз на реальном RS485 в связке с реальными устойствами, внезапно всё работает на ура.

https://info.bma.ai/en/actual/sim/index.html

Еще из обновлений. Убраны генераторы псевдоданных, так как на прошлой неделе EVA ICS получила свой встроенный (https://info.bma.ai/en/actual/eva4/svc/eva-svc-generator.html)

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

Недавно обсуждали, стоит ли собирать десктоп или купить готовый. Я десктопы себе практически не собираю.

- Внезапно, если поймать распродажу, бренд стоит дешевле, чем покупать железо по частям

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

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

- "В бренде есть пропиетарные компоненты, которые не найти". Во-первых - найти, во-вторых - найти клоны, если хочется подешевле. В третьих, чем больше в бренде пропиетарных компонентов, тем больше он представляет коллекционный интерес уже лет через 10. PC/AT-compatible, собранный в подвале, даже если ему 30 лет, не нужен никому даром.

Интересно, только меня Google Play постоянно бесит?

У нас только специфические B2B-аппки, причем они апдейтятся раз в 100 лет. По этой причине у нас нет специального человека, который этим занимается и знает все веяния моды. Ладно там гугл периодически требует поднять target API level, может оно и полезно - вдруг что-то сломали. Но вот это вот заёбывание privacy policy, kids protection, какими-то постоянными сменами форматов ключей - оно обязательно?

Подумываю всё это добро просто хостить с собственной репы. Тем более, что у нас полно кейсов, когда Google Play на target-устройстве забанен, а бывает что его нет вообще и всё равно APK ставится либо с сайта, либо отправляется куда-то там в IT клиента, а они её там уже пихают в устройства.

Google Play, со своими постоянными бюрократическими нововведениями и забиваниями хуёв на совместимость, для кровавого ентерпрайза не подходит. Не побоюсь сказать, не подходит и Android. Вообще сейчас бизнес-платформ для мобилок просто нет, но это у нас время такое говно, нет много чего и другого.

Наши маркетологи:

- нам нужно больше красивых интерфейсов, клиенты это любят, клиенты не понимают консоль

Инженеры наших клиентов, у которых отчеты с 100500 параметров и которые давно мечтающие это заскриптовать

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

Мой Android, ежедневно

Умные книги: Не пишите длинные функции, делайте много маленьких

Yet another issue с гитхаба: ой сколько крутых функций! А почему они все приватные? Открывай, слышь!

Вернемся к программированию конфигураций. Мои соображения

С ЯП общего назначения всё прямо - кроме того, что клиент должен выучить формат вашего деплоя, он должен еще выучить формат классов и функции, чтобы этот деплой генерить, причем у каждого продукта будет свой подход. Это - дорого.

Для начала уберем HCL и Nix lang. Первый - хорош, но задумывался всё же для того функционала, который предоставляет terraform, и эти ноги будут всё равно торчать. Второй - высокий порог входа. Нужно понимать, что конфигурации программируете не только вы, а ваши клиенты, у которых в основном работают девопсы, а не фанаты функционального прораммирования, теории типов, лямбд и прочего искусства.

Dhall. Обрезанный Nix lang. Порог входа - день-два неспеша (для опытного). Язык очень минималистический, не знаю как там сейчас, раньше не было даже сравнения строк. DRY работает нормально, пока вам не нужно что-то более сложное, например банальные list comprehensions делаются через упоротые лямбды. Еще один минус Dhall - абсолютно строгая типизация, вы либо типизируете всё, либо не используете типы вообще (но тогда у вас ни лямбд, ни функций, да и зачем вам тогда Dhall). Учитывая, что конфигурации, как правило - помойки и нужно начинать с чего-то определенного, а не приводить в порядок сразу всё, получаете очень долгий zero to prod (если это вообще возможно). Еще - всё сложное делается через наборы функций (посмотрите хотя бы их пакеты для кубика), а значит клиент опять учит два набора.

Jsonnet. Json и немножко программировая. Порог входа - пару часов неспеша. Язык довольно хорошо развивается, простые list comprehensions, простые функции, простые, но достаточные условия. Минус - бардак, полное отсутствие типизации и прочие прелести, представьте что это JS на минималках.

Альтернативы. Появляются постоянно, но вместо упора на удобство соревнуются в скорости. Нахрена? Конфиги не компилятся в рантайме постоянно. Зато вот что не хватает у всех:

- типизация, но с возможностью условного Any. как в Rust это реализовано с кастомными enums, или возьмите готовый serde_json::Value

- структурные типы с дефолтами. этого почему-то нет вообще. После Rust, где вы можете Default жонглировать как хотите - хоть полностью, хоть частично, попадаете в каменный век.

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

В общем, для меня идеальный язык для конфигураций должен выглядеть как Rust на минималках. Но, естественно, он должен быть а) интерпретируемым б) без жесткого borrow checker в) с автоматическим Clone/ToOwned, чтоб не заёбывать пионеров.

Rust плагин в Idea теперь без поддержки производителя. Зато теперь у них есть очередное платное IDE

Почему я сторонник low code, а не no code в HMI-приложениях.

Вот такая HMI-апка на EVA ICS Webengine React пилится за один рабочий день под ключ и имеет практически неограниченные возможности расширения.

https://eva-demo-turbines.bohemia-automation.com/

Фронт-енд кодеры - больше не кодеры.

Я этот феномен начал замечать давно, но на днях утвердился в этом окончательно.

Dynamic HTML 90х пропустим, настоящий фронт-енд кодинг начался в нулевых, когда энтузиасты случайно обнаружили, что с помощью компонента XMLHttpRequest, который MS вставила в IE для Outlook, можно делать динамические запросы на сервер. Это стало началом эпохи, в которой фронт постепенно стал превращаться из куска серверного MAV в полноценное клиентское приложение, не хуже родного-десктопного.

Начало эпохи было вполне суровым, JS был убогим и тормозил и писать фронт-приложения было целым искусством. Косяки JS и типичные шаблоны заткнули jQuery и так ехали дальше, без особых излишеств.

Пока не появились фреймворки высокого уровня - все эти самые React, Vue, Angular и прочее. А с ними - новое поколение кодеров, которые от Vanilla JS делают круглые глаза. Они не понимают, как работают хуки реакта под капотом, копи-пастая примеры и пробуя наугад. Они не могут написать компонент с элементарной логикой, только импортнуть готовый. Они ходят на курсы, где их учат клепать детдомовские приложения, похожие друг на друга все как один, а потом пытаются двигать тот же детдом в прод.

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

У меня сейчас наступила пора TypeScript и я заметил, что больше всего мне не хватает енумов с прицепами.

Когда начинаешь в Rust, этот тактически-архитектурный прием кажется странным, даже неудобным, но очень быстро на него подсаживаешься.

В TS конечно это решается чем-то типа interface { kind: EnumKind, data?: any }, но в целом с этим печально.

А где еще есть у енумов ассоциированные типы? На память приходит только Swift.

Недавно наконец перелез на Rust 1.7x, где они по-умолчанию начали включать второй resolver и сразу началось веселье.

Вот такая конфигурация

[dependencies]
sqlx = { version = "0.7", features = ["runtime-tokio-native-tls"] }
openssl = { version = "0.10.57", features = ["vendored"] }

прекрасно собирается (считаем что libssl-dev нет на машине) с первым резолвером, но совершенно не хочет со вторым и упорно ищет системный openssl. Причем, если взять совершенно-любой-другой-крейт (в том числе native-tls, на котором сидит sqlx) и включать там openssl-vendored не его собственными средствами (у sqlx нет feature напрямую), а вот так, глобально, то всё внезапно тоже собирается.

Вопрос к студии - это resolver новый барахлит, или sqlx как обычно такой поехавший? Причем, что характерно, с sqlx 0.5 проблем опять же нет (его не собрать 1.7 компилятором, но openssl собираться успевает), а вот с 0.6 уже есть. Как sqlx постоянно умудряется собрать все возможные и невозможные баги на пустом месте?