Ещё в качестве примера программирования без переменных можно привести графическое программирование, основанное на парадигме потоков данных (Data Flow).
Предположим я хочу вычислить (x+y)*z. Можно сделать вот так, заведя переменные (так обычно не делают, но тем не менее), в LabVIEW вот так:
Но можно выкинуть все переменные, оставив лишь потоки данных (так обычно и делают)
Ну и поскольку имена переменных имеют лишь номинальное значение, а мы всё равно в хабе "ненормальное програмирование", а с фантазией у нас не очень, то можно обойтись одним именем "а", и сделать вот так:
И если в вашем мозговыносящем примере, слегка поднапрягшись, таки ещё можно сказать о результате выполнения кода, то в данном случае, глядя на код, уже невозможно наверняка утверждать, какой получится результат, не запустив его. Конечно, статический анализатор вывалит кучу предупреждений, но формально этот код вполне себе валиден. По большому счёту при программировании на "потоках данных" переменные — вообще зло, они "разбивают" потоки данных и в этом смысле сродни оператору GoTo.
Я не являюсь профессиональным вирусологом или микробиологом, чтобы утверждать это наверняка, без сомнений, хотя я полюбопытствовал, даже скачав геном этого вируса и био софт и стараясь разобраться в статьях про белки и всё такое (в карантин было нечем заняться) но там требуется поднять довольно большой пласт знаний, а я физик по образованию. Для себя я сделал вывод, что эта штука похожа на маленького робота, в её устройстве в общем неплохо разобрались. Меня зацепили два факта - это началось очень резко, и хотя коронавирусы известны давно, но ярких вспышек там и сям я как-то не припомню, а они, вероятно, с постепенными мутациями, должны были предшествовать большой пандемии. Ну и помимо того, что это столь лавинообразно началось, так это случилось прямо возле биолаборатории, вот ведь как им с местом не повезло. А с летучими мышками-носителями заражёнными места там тоже есть, да, но вроде чуть отдалённее. Так что я за пробирку, хотя это просто моё ничем не подкреплённое субъективное мнение, которое тем не менее имею право высказать. Тесть мой, ещё не старый, этой штукой заразился - полторы недели в реанимации и нет его.
у людей, у которых хватает интеллекта чтобы работать в 1 из 2 лабораторий в мире и собрать вирус по техзаданию, не хватает интеллекта, чтобы отъехать в другой населённый пункт дабы поселить его in vivo.
Я считаю, что кто-то просто грохнул пробирку по неосторожности, не соблюдая ТБ, потом сходил на рынок купить покушать и приехали. Но истины мы скорее всего уже не узнаем.
Спасибо! У меня, правда есть некоторые специфические требования, типа проекты с идентификаторами и "активность" (так как я это в SAP потом забиваю), но это всё решаемо. Я сейчас просто в Excel учёт веду, и далеко не всё мне нравится.
У меня, читая это, сразу родился план тайм трекера. Надо будет попробовать, там допилить всего ничего. Тайм трекеров куча, в том числе для Обсидиана, но что-то в этом подходе есть.
А в каких сценариях реального использования может пригодится такой функционал?
Как пример — предположим у меня есть ПЛК, наружу из него торчит Modbus TCP, и я разрабатываю десктопное приложение, которое с ним общается. Держать ПЛК на столе неудобно, соответственно программа выступает "заглушкой", к которой я и подсоединяюсь вместо настоящей железки. Ну и когда я что-то пишу, то сразу вижу чего и в какой регистр записалось (на самом ПЛК это смотреть опять же не всегда удобно), ну и вручную могу какие-то регистры установить и их читать. Логики там не надо, просто статические регистры. Этакий примитивный "эмулятор". Ещё вот был случай, когда соединение разрывалось по таймауту, и чтобы определить, какая сторона "глючит", такая "независимая" программа была бы кстати.
В принципе, конечно, разные, хотя это не мешает и их сравнивать. Modbus с Profibus тоже в общем сравниваются с некоторой натяжкой. Я просто общий тренд в промышленной автоматизации имел ввиду.
Мне в LabVIEW комменты нравятся, поскольку это графическое программирование, то и комменты можно картинками разбавлять (кстати, удобно, когда формулы и графики), но там также и анимированные гифки можно вставлять (они при компиляции удаляются).
Profibus обеспечивает более скоростную связь, чем Modbus.
К этой фразе можно придраться, тем более вы сами ниже про Modbus пишете, что "До 19,2 Кбит/с в последовательном режиме, выше в TCP/IP". В теории фреймы Modbus можно и через гигабитную сетку гонять, лишь бы устройства с обеих сторон поддерживали.
Вообще я в данный момент наблюдаю массовый переход на Profinet и OPC UA, уже много лет ни в одной новой системе мы что Profibus, что Modbus не использовали.
Муж моей двоюродной сестры смог за короткий срок (для Германии) зарегистрировать фирму, без которой мы не имели бы право стартовать.
Любопытно, а просто зарегистрироваться как Selbständig (что занимает 20 минут в Ратуше и 20 евро) было в данном случае недостаточно (теоретически ведь могло бы прокатить из разряда "Freie Berufe" со всякими wissenschaftliche бла бла бла) или нет?
Я не из радиологии, но из радиографии, причём промышленной. По существу вопроса имею сказать следующее — на волне хайпа в ИИ многие производители промышленного оборудования утверждают "да у нас тут ИИ в полный рост". На поверку же оказывается мягко говоря не совсем так. Типичный пример — батареи для электромобилей/планшетов/смартфонов, их сейчас иногда проверяют рентгеном, делая томографию (частичную или полную), и проверяют геометрию катодов и анодов с точки зрения перехлёста, деформации и т.п. Так вот когда начинаешь дотошно выяснять — тут оказывается Canny, там Sobel, а потом классическая аналитическая геометрия и ни намёка на машинное обучение. Очевидно, что классическое ML тут задача нетривиальная, хотя бы в том, что батареи все разные, набрать хоть сколько-нибудь приемлемый по размеру сет для тренинга — непросто, просто нет столько дефектных. С дефектами литья тоже самое — в лучшем случае машинное обучение используется в небольшой части общего пайплайна обработки картинок (скажем в бинарной классификации), а большая часть процессинга — классика на модифицированных медианных фильтрах или около того. В медицине ситуация чуть проще в том, что все люди плюс-минус однаковы с точки зрения внутреннего устройства, а вот головка блока циилиндров несколько отличается от рычагов подвески, да и даже в пределах одного производителя конструктивные особенности и геометрия могут быть принципиально различны. На Kaggle, кстати, выкладывали много изображений поражения лёгких при Covid, и там методы машинного обучения вполне себе успешно использовались, хотя о практическом применении я честно не слышал, хотя статей типа Hospital-wide survey of clinical experience with artificial intelligence applied to daily chest radiographs встречал довольно много (но это опять же не моя область). Технически там обычно на DICOM всё нанизано, и воткнуться в цепь обработки можно, но нужно ещё передать результаты дальше, в какие-то теги это записать, конечное ПО (которое ещё надо сертифицировать) должно всё это поддерживать и т.д. В промышленности мы DICONDE используем, что в общем тоже самое, только вид сбоку. Но факт в том, что от демки, открывающей dcm файл и показывающей результат, до интегрированного решения — как от земли до неба (хотя тут скорее просто рутинное программирование). Ещё есть чисто технические затыки. Вот прямо сейчас я неспешно сращиваю поиск дефектов с YOLO 8.1 (там ввели ориентированные регионы — это когда я не просто прямоугольник в ответ получаю, а повёрнутый), так вот, картинки-то у меня 16 бит, и YOLO банально их не понимает. И хотя в теории это можно допилить, на практике это непросто там кода дофига. Народ просил поддержку 16 бит в прошлом году, но пока висит статус "не планируется". Да даже и с разметкой датасета в YOLO 8.1 — информации ноль, в каком формате это подавать, есть примеры предобученных сеток, и они вполне себе успешно находят всякие объекты, но когда у вас есть просто набор 16 бит картинок, то от него до обученной функциональной сетки — очень большая дистанция. То есть ещё работать и работать. Но потенциал тут есть определённо. Уже есть довольно большие наборы данных, полученных на "классических" алгоритмах, хотя и тут в промышленности есть тонкость — эти данные не публичные, внутреннее устройство деталей — это закрытая интеллектуальная собственность. Пока что для предварительных "пристрелочных" упраженний я просто генерирую искуственные дефекты, слегка корёжа их морфологией, но через всё приходится продираться как через лесную чащу.
Детская кроватка напомнила мне историю десятилетней давности. Короче, когда дети подросли, им понадобились полноразмерные кровати, но ни одна из "готовых" типа Икеевских нам отчаянно не нравилась (хотелось из чистого массивного дерева, огороженную с трёх сторон с красивыми резными элементами и т.д.). Изготовление такой под заказ (а мы территориально в Германии) выливалось в четырёхзначную сумму, а нам их надо две. Короче, тёща нашла фирму в Карелии, там их сделали именно так, как нам хотелось, супруга с детишками слетала домой и вместо багажа назад привезла на самолёте две кровати в разобранном виде. Даже с учётом билетов и доплаты всё это обошлось в несколько раз дешевле. Зато дома теперь кровати "с историей", каких больше ни у кого тут нет. По качеству — практически без претензий, разве что крепёж я при сборке заменил на помощнее.
TIFF форматом мы тоже пользуемся, и в основном если нужно отдать данные заказчику, а формат DICONDE он по какой-то причине не хочет. PNG это "внутренний формат", дело в том, что картинки наши содержат калибровочную информацию, разметку и т.д., так в библиотеке это пара функций, вот этих — IMAQ Write Image And Vision Info File и IMAQ Read Image And Vision Info, но они только для PNG, для TIFF таких нет. Если же я буду использовать TIFF, то мне придётся всё тоже самое реализовать руками, либо с libtiff повозиться. Конкретный заказчик решил воспользоваться нашими внутренними данными в PNG для обучения ML модели (c обучением модели он, кстати, так и не справился, также как изначально не понял устройство PNG).
Ноутбук нужен только тем, кто с ним постоянно куда-то ходит. Всем остальным ноутбук не нужен.
Вы напрасно столь радикально, у меня на кухне ноутбук лежит для утреннего кофе (вот и сейчас я с него пишу). Но это рабочая станция 17 дюймов и весит под четыре кило. "Постоянно ходить" с ним мягко говоря не очень, а держать на кухонном подоконнике — норм, а вот десктоп на кухне мне точно не нужен. Однако в комнате у меня именно десктоп, причём самосборный в винтажном корпусе (ну нравится мне Dell XPS) и работа с ним доставляет мне эстетическое удовольствие.
У меня пара таких корпусов, так что один было не жалко пустить под апгрейд и вкорячить туда современную материнку, графику, i7, ssd и всё такое.
Да, есть такое дело, чем-то напоминает НИИ Точной Механики и оптики, где я в середине восьмидесятых практику проходил. Тут всё как надо - есть профсоюз, профком, начальник профкома, тарифная таблица, тринадцатая зарплата, и т.д. Но в общем есть и плюсы - рабочая неделя 35 часов, отпуск 30 рабочих дней, все переработки оплачиваются с первой минуты, точнее обычно заставляют эти часы к отпуску прибавлять, мой "рекорд" - одиннадцать недель отпуска. Более десяти часов в сутки работать запрещено. Работа в субботу +25%, в воскресенье и праздники +50%, профсоюз иногда устраивает забастовки и митинги на тему повышения зарплаты, длительные командировки только бизнес-классом, служебный автомобиль, бесплатная зарядка личных электромобилей, в общем жить можно, даже весело местами.
У нас в контракте 45 минут даётся - 15 мин на завтрак и 30 мин на обед. Время не включено в рабочее. Причём обед в две смены - половина сотрудников должна обедать с 12:15 до 12:45, а вторая - 12:45 - 13:15, типа чтоб эффективнее было. Народ не то чтобы педантично соблюдает, но иногда босса пробивает, он сам встаёт на проходной и начинает ловить тех, кто режим не блюдёт, потом выговор и лишение премии. А, и перекуры не включены - вышел на перекур - приложил бейджик, вернулся - снова приложил (а при выходе на обед прикладывать не надо, там само учитывается). Дело в Германии.
Может если сделать чёрный фон и зелёные буквы, да отключить подсветку синтаксиса, то почти как ДВК получится. Надо будет на досуге сравнить. Но постоянно так работать мне кажется ну такое.
Хотя ко всему можно привыкнуть. Я вот переехал на PT Mono со старого нового курьера. Правда я долго привыкал, чуть ли не несколько месяцев. Когда первый раз поставил - ну ужас же, да и на Хабре его ругали. Потом снова поставил — ну да, ужас, но не ужас-ужас. Так несколько раз туда-сюда попрыгал, да как-то так и остался на нём, что-то в нём есть.
О, у меня как раз прошлым летом был интереснейший проект, где мне пришлось это учитывать. Суть в том, что некая система роняет некий объект с двухметровой высоты на гранитную плиту, а несколько высокоскоростных камер (до 40К картинок в секунду) с разных сторон наблюдают что происходит с объектами в момент удара. Ну и для начала захвата изображений и включения рентгена мне нужно было знать точное время от пролёта сенсора до удара, так что ускорение свободного падения пришлось сделать настраиваемым (таких систем несколько, работают в разных широтах). Получил незабываемое наслаждение на пусконаладке, вдребезги разбив кучу инженерных семплов топовейшей электроники.
Да, и вдогонку — коммент, не имеющий отношения к 16 бит, но имеющий отношение к PNG и LabVIEW.
Часть скриншотов в этой статье непростые, некоторые из них — "сниппеты", они несут как раз дополнительную нагрузку в виде кода, которой вы не видите, но она есть. Об этом говорит рамочка вокруг них, а цифра 2024 означает версию LabVIEW, в которой они были созданы. Если вы сохраните оригинальную картинку из поста к себе на десктоп:
а потом перетащите её прямо на блок-диаграмму LabVIEW 2024, то вы получите исходный код, который можно редактировать:
Как это достигается, легко понять, открыв файл в том же tweakpng, вы там увидите пару дополнительных тегов - текстовый коммент и собственно приватный тег niVI, который и содержит код, как есть:
Спасибо Хабру за то, что он не прибивает "ненужную" инфу в PNG при загрузке через habrastorage.
Ещё в качестве примера программирования без переменных можно привести графическое программирование, основанное на парадигме потоков данных (Data Flow).
Предположим я хочу вычислить (x+y)*z. Можно сделать вот так, заведя переменные (так обычно не делают, но тем не менее), в LabVIEW вот так:
Но можно выкинуть все переменные, оставив лишь потоки данных (так обычно и делают)
Ну и поскольку имена переменных имеют лишь номинальное значение, а мы всё равно в хабе "ненормальное програмирование", а с фантазией у нас не очень, то можно обойтись одним именем "а", и сделать вот так:
И если в вашем мозговыносящем примере, слегка поднапрягшись, таки ещё можно сказать о результате выполнения кода, то в данном случае, глядя на код, уже невозможно наверняка утверждать, какой получится результат, не запустив его. Конечно, статический анализатор вывалит кучу предупреждений, но формально этот код вполне себе валиден. По большому счёту при программировании на "потоках данных" переменные — вообще зло, они "разбивают" потоки данных и в этом смысле сродни оператору GoTo.
Я не являюсь профессиональным вирусологом или микробиологом, чтобы утверждать это наверняка, без сомнений, хотя я полюбопытствовал, даже скачав геном этого вируса и био софт и стараясь разобраться в статьях про белки и всё такое (в карантин было нечем заняться) но там требуется поднять довольно большой пласт знаний, а я физик по образованию. Для себя я сделал вывод, что эта штука похожа на маленького робота, в её устройстве в общем неплохо разобрались. Меня зацепили два факта - это началось очень резко, и хотя коронавирусы известны давно, но ярких вспышек там и сям я как-то не припомню, а они, вероятно, с постепенными мутациями, должны были предшествовать большой пандемии. Ну и помимо того, что это столь лавинообразно началось, так это случилось прямо возле биолаборатории, вот ведь как им с местом не повезло. А с летучими мышками-носителями заражёнными места там тоже есть, да, но вроде чуть отдалённее. Так что я за пробирку, хотя это просто моё ничем не подкреплённое субъективное мнение, которое тем не менее имею право высказать. Тесть мой, ещё не старый, этой штукой заразился - полторы недели в реанимации и нет его.
Я считаю, что кто-то просто грохнул пробирку по неосторожности, не соблюдая ТБ, потом сходил на рынок купить покушать и приехали. Но истины мы скорее всего уже не узнаем.
Спасибо! У меня, правда есть некоторые специфические требования, типа проекты с идентификаторами и "активность" (так как я это в SAP потом забиваю), но это всё решаемо. Я сейчас просто в Excel учёт веду, и далеко не всё мне нравится.
У меня, читая это, сразу родился план тайм трекера. Надо будет попробовать, там допилить всего ничего. Тайм трекеров куча, в том числе для Обсидиана, но что-то в этом подходе есть.
Как пример — предположим у меня есть ПЛК, наружу из него торчит Modbus TCP, и я разрабатываю десктопное приложение, которое с ним общается. Держать ПЛК на столе неудобно, соответственно программа выступает "заглушкой", к которой я и подсоединяюсь вместо настоящей железки. Ну и когда я что-то пишу, то сразу вижу чего и в какой регистр записалось (на самом ПЛК это смотреть опять же не всегда удобно), ну и вручную могу какие-то регистры установить и их читать. Логики там не надо, просто статические регистры. Этакий примитивный "эмулятор". Ещё вот был случай, когда соединение разрывалось по таймауту, и чтобы определить, какая сторона "глючит", такая "независимая" программа была бы кстати.
В принципе, конечно, разные, хотя это не мешает и их сравнивать. Modbus с Profibus тоже в общем сравниваются с некоторой натяжкой. Я просто общий тренд в промышленной автоматизации имел ввиду.
Навскидку проверил с библиотекой NI Modbus, и оно работает, спасибо!
А сервером (в смысле слейвом) ваша программа может выступать? Ну чтобы она просто слушала 502-й порт, а я бы к ней подключился?
Мне в LabVIEW комменты нравятся, поскольку это графическое программирование, то и комменты можно картинками разбавлять (кстати, удобно, когда формулы и графики), но там также и анимированные гифки можно вставлять (они при компиляции удаляются).
Баг как есть:
К этой фразе можно придраться, тем более вы сами ниже про Modbus пишете, что "До 19,2 Кбит/с в последовательном режиме, выше в TCP/IP". В теории фреймы Modbus можно и через гигабитную сетку гонять, лишь бы устройства с обеих сторон поддерживали.
Вообще я в данный момент наблюдаю массовый переход на Profinet и OPC UA, уже много лет ни в одной новой системе мы что Profibus, что Modbus не использовали.
Любопытно, а просто зарегистрироваться как Selbständig (что занимает 20 минут в Ратуше и 20 евро) было в данном случае недостаточно (теоретически ведь могло бы прокатить из разряда "Freie Berufe" со всякими wissenschaftliche бла бла бла) или нет?
Я не из радиологии, но из радиографии, причём промышленной. По существу вопроса имею сказать следующее — на волне хайпа в ИИ многие производители промышленного оборудования утверждают "да у нас тут ИИ в полный рост". На поверку же оказывается мягко говоря не совсем так. Типичный пример — батареи для электромобилей/планшетов/смартфонов, их сейчас иногда проверяют рентгеном, делая томографию (частичную или полную), и проверяют геометрию катодов и анодов с точки зрения перехлёста, деформации и т.п. Так вот когда начинаешь дотошно выяснять — тут оказывается Canny, там Sobel, а потом классическая аналитическая геометрия и ни намёка на машинное обучение. Очевидно, что классическое ML тут задача нетривиальная, хотя бы в том, что батареи все разные, набрать хоть сколько-нибудь приемлемый по размеру сет для тренинга — непросто, просто нет столько дефектных. С дефектами литья тоже самое — в лучшем случае машинное обучение используется в небольшой части общего пайплайна обработки картинок (скажем в бинарной классификации), а большая часть процессинга — классика на модифицированных медианных фильтрах или около того. В медицине ситуация чуть проще в том, что все люди плюс-минус однаковы с точки зрения внутреннего устройства, а вот головка блока циилиндров несколько отличается от рычагов подвески, да и даже в пределах одного производителя конструктивные особенности и геометрия могут быть принципиально различны. На Kaggle, кстати, выкладывали много изображений поражения лёгких при Covid, и там методы машинного обучения вполне себе успешно использовались, хотя о практическом применении я честно не слышал, хотя статей типа Hospital-wide survey of clinical experience with artificial intelligence applied to daily chest radiographs встречал довольно много (но это опять же не моя область). Технически там обычно на DICOM всё нанизано, и воткнуться в цепь обработки можно, но нужно ещё передать результаты дальше, в какие-то теги это записать, конечное ПО (которое ещё надо сертифицировать) должно всё это поддерживать и т.д. В промышленности мы DICONDE используем, что в общем тоже самое, только вид сбоку. Но факт в том, что от демки, открывающей dcm файл и показывающей результат, до интегрированного решения — как от земли до неба (хотя тут скорее просто рутинное программирование). Ещё есть чисто технические затыки. Вот прямо сейчас я неспешно сращиваю поиск дефектов с YOLO 8.1 (там ввели ориентированные регионы — это когда я не просто прямоугольник в ответ получаю, а повёрнутый), так вот, картинки-то у меня 16 бит, и YOLO банально их не понимает. И хотя в теории это можно допилить, на практике это непросто там кода дофига. Народ просил поддержку 16 бит в прошлом году, но пока висит статус "не планируется". Да даже и с разметкой датасета в YOLO 8.1 — информации ноль, в каком формате это подавать, есть примеры предобученных сеток, и они вполне себе успешно находят всякие объекты, но когда у вас есть просто набор 16 бит картинок, то от него до обученной функциональной сетки — очень большая дистанция. То есть ещё работать и работать. Но потенциал тут есть определённо. Уже есть довольно большие наборы данных, полученных на "классических" алгоритмах, хотя и тут в промышленности есть тонкость — эти данные не публичные, внутреннее устройство деталей — это закрытая интеллектуальная собственность. Пока что для предварительных "пристрелочных" упраженний я просто генерирую искуственные дефекты, слегка корёжа их морфологией, но через всё приходится продираться как через лесную чащу.
Детская кроватка напомнила мне историю десятилетней давности. Короче, когда дети подросли, им понадобились полноразмерные кровати, но ни одна из "готовых" типа Икеевских нам отчаянно не нравилась (хотелось из чистого массивного дерева, огороженную с трёх сторон с красивыми резными элементами и т.д.). Изготовление такой под заказ (а мы территориально в Германии) выливалось в четырёхзначную сумму, а нам их надо две. Короче, тёща нашла фирму в Карелии, там их сделали именно так, как нам хотелось, супруга с детишками слетала домой и вместо багажа назад привезла на самолёте две кровати в разобранном виде. Даже с учётом билетов и доплаты всё это обошлось в несколько раз дешевле. Зато дома теперь кровати "с историей", каких больше ни у кого тут нет. По качеству — практически без претензий, разве что крепёж я при сборке заменил на помощнее.
TIFF форматом мы тоже пользуемся, и в основном если нужно отдать данные заказчику, а формат DICONDE он по какой-то причине не хочет. PNG это "внутренний формат", дело в том, что картинки наши содержат калибровочную информацию, разметку и т.д., так в библиотеке это пара функций, вот этих — IMAQ Write Image And Vision Info File и IMAQ Read Image And Vision Info, но они только для PNG, для TIFF таких нет. Если же я буду использовать TIFF, то мне придётся всё тоже самое реализовать руками, либо с libtiff повозиться. Конкретный заказчик решил воспользоваться нашими внутренними данными в PNG для обучения ML модели (c обучением модели он, кстати, так и не справился, также как изначально не понял устройство PNG).
Вы напрасно столь радикально, у меня на кухне ноутбук лежит для утреннего кофе (вот и сейчас я с него пишу). Но это рабочая станция 17 дюймов и весит под четыре кило. "Постоянно ходить" с ним мягко говоря не очень, а держать на кухонном подоконнике — норм, а вот десктоп на кухне мне точно не нужен. Однако в комнате у меня именно десктоп, причём самосборный в винтажном корпусе (ну нравится мне Dell XPS) и работа с ним доставляет мне эстетическое удовольствие.
У меня пара таких корпусов, так что один было не жалко пустить под апгрейд и вкорячить туда современную материнку, графику, i7, ssd и всё такое.
Да, есть такое дело, чем-то напоминает НИИ Точной Механики и оптики, где я в середине восьмидесятых практику проходил. Тут всё как надо - есть профсоюз, профком, начальник профкома, тарифная таблица, тринадцатая зарплата, и т.д. Но в общем есть и плюсы - рабочая неделя 35 часов, отпуск 30 рабочих дней, все переработки оплачиваются с первой минуты, точнее обычно заставляют эти часы к отпуску прибавлять, мой "рекорд" - одиннадцать недель отпуска. Более десяти часов в сутки работать запрещено. Работа в субботу +25%, в воскресенье и праздники +50%, профсоюз иногда устраивает забастовки и митинги на тему повышения зарплаты, длительные командировки только бизнес-классом, служебный автомобиль, бесплатная зарядка личных электромобилей, в общем жить можно, даже весело местами.
У нас в контракте 45 минут даётся - 15 мин на завтрак и 30 мин на обед. Время не включено в рабочее. Причём обед в две смены - половина сотрудников должна обедать с 12:15 до 12:45, а вторая - 12:45 - 13:15, типа чтоб эффективнее было. Народ не то чтобы педантично соблюдает, но иногда босса пробивает, он сам встаёт на проходной и начинает ловить тех, кто режим не блюдёт, потом выговор и лишение премии. А, и перекуры не включены - вышел на перекур - приложил бейджик, вернулся - снова приложил (а при выходе на обед прикладывать не надо, там само учитывается). Дело в Германии.
Может если сделать чёрный фон и зелёные буквы, да отключить подсветку синтаксиса, то почти как ДВК получится. Надо будет на досуге сравнить. Но постоянно так работать мне кажется ну такое.
Хотя ко всему можно привыкнуть. Я вот переехал на PT Mono со старого нового курьера. Правда я долго привыкал, чуть ли не несколько месяцев. Когда первый раз поставил - ну ужас же, да и на Хабре его ругали. Потом снова поставил — ну да, ужас, но не ужас-ужас. Так несколько раз туда-сюда попрыгал, да как-то так и остался на нём, что-то в нём есть.
О, у меня как раз прошлым летом был интереснейший проект, где мне пришлось это учитывать. Суть в том, что некая система роняет некий объект с двухметровой высоты на гранитную плиту, а несколько высокоскоростных камер (до 40К картинок в секунду) с разных сторон наблюдают что происходит с объектами в момент удара. Ну и для начала захвата изображений и включения рентгена мне нужно было знать точное время от пролёта сенсора до удара, так что ускорение свободного падения пришлось сделать настраиваемым (таких систем несколько, работают в разных широтах). Получил незабываемое наслаждение на пусконаладке, вдребезги разбив кучу инженерных семплов топовейшей электроники.
Да, и вдогонку — коммент, не имеющий отношения к 16 бит, но имеющий отношение к PNG и LabVIEW.
Часть скриншотов в этой статье непростые, некоторые из них — "сниппеты", они несут как раз дополнительную нагрузку в виде кода, которой вы не видите, но она есть. Об этом говорит рамочка вокруг них, а цифра 2024 означает версию LabVIEW, в которой они были созданы. Если вы сохраните оригинальную картинку из поста к себе на десктоп:
а потом перетащите её прямо на блок-диаграмму LabVIEW 2024, то вы получите исходный код, который можно редактировать:
Как это достигается, легко понять, открыв файл в том же tweakpng, вы там увидите пару дополнительных тегов - текстовый коммент и собственно приватный тег niVI, который и содержит код, как есть:
Спасибо Хабру за то, что он не прибивает "ненужную" инфу в PNG при загрузке через habrastorage.