Бесконечный скролл - это только половина зла, а вот полное всеобъемлющее зло наступает тогда, когда на странице еще есть некий footer с важной информацией, до которого пытаешься "домотать".
Вы еще вспомните тех чрезвычайно богатых типов, которые залезли в бочку и нырнули на 3+ километров, хотя даже школьный курс физики подсказывает, что бочка, да еще и из совершенно разных материалов - это не самая оптимальная форма для больших глубин.
Эх, как-то совершенно бездуховно что ли. А ведь можно было попросить какой-нибудь ChatGPT написать скрипт, который бы мониторил Google Drive, брал из него новый файл, выдергивал из него данные, вставлял в svg-шаблон, затем через какой-нибудь cairosvg конвертировал в pdf с последующей растеризацией через ghostscript, и отсылал полученный результат на указанную в файле почту.
Ну, как говорится, не все так однозначно. Вот взять "огромное количество сред разработки" - не такое и огромное, если сравнивать с количеством web-фрейворков на JS, где каждый день выходит новый, с очередной революционной (той или иной степени) идеей. Да и урезанность ЯП в этой сфере - вещь относительная, ведь задачи на нижнем уровне, как правило, весьма однотипные, а если данные ушли наверх, то там уже делай с ними что хочешь и с помощью чего хочешь (порой даже за гранью добра - однажды видел развесистую статистическую систему, написанную на Visual Basic, которую тащили на своем горбу с середины 90-х). Но зачастую этого и не требуется, т.к. большинство задач вполне решаются в рамках выбранной экосистемы того или иного производителя, собрав простыню из FBD на десяток-другой экранов. Отсутствие разделения труда - тоже спорно. К примеру, еще лет 20 назад, когда я занимался АСУ ТП, у нас была четкая дифференциация штанов: монтажники, электрики, электронщики, наладчики, КИПиА, проектировщики, и отдельной кастой шел отдел инженеров и прочих программистов. Возможно, что в небольших компаниях еще можно встретить "фулл-стек" мастеров от АСУТП - от монтажных работ по пояс в нечистотах, до разработки драйверов какого-нибудь эзотерического оборудования (впрочем, и тут, скорее всего, придется работать в поле, т.к. железо будет в работе и никто не даст его для экспериментов в стерильную лабораторию). Но сомневаюсь, что в этом случае будет высокая производительность труда. Впрочем, возможно, что мне просто повезло с компанией (а точнее с региональным подразделением, где у нас уже тогда была и удаленка, и относительно свободный график, и машина с водителем, и бильярдная со штангой, и даже чайник с безлимитными печенюшками и 3-х литровой банкой заварки - все те "блага", которые лишь потом стали "стандартом" отрасли). Тем не менее, проблема разделения и условий труда решаема в пределах той или иной организации, было бы желание. Тоже самое касается качества кода и его сопровождения. 20 лет назад уже использовалась CVS везде, где можно было экспортировать в текстовый вид, а где нельзя - просто бинарными файлами, что при наличии документации и качественного комментирования коммитов давало хоть какое-то версионирование и уверенность в завтрашнем дне. Особенную радость в то время вызвало появление Tortoise CVS и затем SVN - даже проектантов удалось перетащить c VSS. Да и связь между удаленными офисами кое-как наладили, пусть и с ограничениями того времени - модемы на отправку, спутник на прием, ну и более-менее быстрый (по меркам того времени) Интернет как бонус. Поэтому чисто там, где не мусорят культура разработки есть там, где ей уделяют должное внимание. Ну а что касается открытых решений, то тут не поспоришь - как вспомню написание OPC гейтвейта, без возможности купить стандарт и имея под рукой только тулзу для тестирования интерфейсов OPC, так аж нехорошо становится. Но нужно ли это производителям ? Вот это вопрос.
Экологичнее - это факт. Еще бы им не быть экологичнее, если к ним прикручены рециркуляции, рекуперации, катализаторы и прочие сажевые фильтры. Но вот то, что они стали сильно меньше расходовать топлива, а главное - стали дешевле в производстве - это не так очевидно. 20 лет назад я на универсале (Пассат Б3 с 1.6) по трассе укладывался в 6-7 литров на сотню, что сейчас схожие по размеру машины с похожим объемом двигателя кушают по 5-6 литров. Разница есть, но без вау эффекта. Но там, простите, был совершенно примитивный двигатель с самым обычным моновпрыском. Сейчас мы имеем двигатели с распределенным впрыском, насос-форсунками, работающие на более высокой степени сжатия, имеющими более сложный обвес (по сравнению с тем древним моновпрыском, которому для работы было нужно 3 датчика). Не уверен, что современный двигатель будет дешевле в производстве. Поэтому если и видно развитие, то только в сторону получения более высоких показателей при одновременном повышении экологичности, но скорее всего в ущерб стоимости.
Ммм, и давно 2600 км стало смерти подобно для обычного человека? За сутки, разумеется, нереально - из подобий автобанов у нас, на вскидку, могу назвать только Москва-Питер, где можно без нарушений ехать 130, но 1300 км легко проезжаются за световой (с небольшим захватом рассвета-сумерек) день в расслабленном темпе и по обычным трассам. По крайней мере в левой части глобуса России, где есть нормальная дорога от Баренцева до самого Черного моря, спокойно проезжаемая (по своему опыту) за 3 дня - умываемся на побережье Баренцева моря, день до Питера, день до Воронежа и глубоким вечером на 3 день вы уже моете сапоги в Черном море. Соглашусь, что такие поездки нужны не всем, да и чаще чем 2-3 раза в год вряд ли востребованы, но само осознание возможности такой свободы и независимости в передвижении дорого стоит. Собственно, разве автомобиль и не создан ради такой свободы? Поэтому остается только ждать революции-эволюции возможности аккумулировать больше энергии и заливать ее в аккумуляторы через проводники разумного сечения.
Думал зайти, написать о том, как же утомили ежедневные посты (и это на профильном ресурсе, где находятся те, кто уже так или иначе там) про то, как войтивайти не вставая с дивана, а тут, наконец-то, дельная информация.
Вы смешиваете плановый, неплановый, текущий и капитальный ремонт. Если срок службы условного исполнительного механизма какого-либо оборудования 100.000 часов, то либо он будет заменен не более чем через 100.000 часов работы и вне зависимости от показателей работы снятых с каких либо датчиков, либо решение принимается по результатам мониторинга (на любой выбор — датчики температуры, вибрации, токопроводности, визуальный контроль или даже просто «ой, Михалыч, чувствую, что сейчас все эммм… сломается»), что в определенных ситуациях, разумеется, дает возможность значительно увеличить срок службы тех или иных агрегатов. Это лишь вопрос отвественности той или иной стороны, а так же вероятности волшебной трансформации планового ремонта в неплановый со всеми вытекающими. В случае выхода этого условной детали или агрегата из строя ранее установленного заводом-изготовителем срока службы — ответственность ложится на одну сторону. В случае превышения установленного срока службы вы все риски ложатся на другую. Стоит ли они того — это, конечно, решает каждый сам, для каждой конкретной ситуации. В любом случае, замена по результатам оценки установленного нормами технического состояния — это обычный плановый ремонт, в этом нет ничего нового. И все это существует и работает не один десяток лет. Поэтому ноу-хау какое-то странное — вроде подается как что-то новое и невероятно революционное, а по факту 20+ лет назад все это уже было. Это что касается ТР.
Другое дело КП, когда по совокупности накопленного износа (или даже других факторов, на которые мы не можем повлиять никакими измерениями, например фактором сезонности, контрактных или гарантийных обязательств) основного оборудования нет возможности продолжать работу без полной остановки ТП и/или переходе на резерв. Иногда сроки КП можно отодвинуть на основании текущих показателей, но иногда это невозможно, даже если все показатели в норме. Примеров можно привести массу, к примеру, возьмем какой-нибудь турбодетандер разложения воздуха, допустим Ротофлоу, который устанавливается поставщиком и для обслуживания которого у нас нет ни квалификации, ни опыта (или как сейчас модно говорить — экспертизы). Согласно обязательствам срок службы агрегата 5 лет (условно), а значит, хотим мы этого или нет, но через 5 лет либо приедет фура с новым турбодетандером и он будет заменен целиком, либо будет произведен КП по месту.
Простите, но аналогия немного неверная. Информация «о километраже» любого оборудования на предприятии известна — будь то двигатель приточной вентиляции, флотационные насосы, ТЭНы, МЭО, погрузчики, форсунка плавильной печи, датчик уровня и вплоть до болтовых и клепаных соединений (обвешивание которых датчиками порой совершенно нерационально). Любой завод/комбинат — это прежде всего непрерывность производства на определенных отрезках времени, и сроки ППР закладываются чуть-ли не на этапе проектирования, на основании опыта эксплуатации схожих ТП, которые в дальнейшем определяются опытом конкретной эксплуатации в сложившихся условиях. Отсюда вытекает и резервирование, и классическая схема для жизненно важных для производства техпроцессов (например, кислородные цеха металлургических предприятий): в_работе — в_резерве — в_ремонте, ведь ППР — это не только профилактическая замена «рулевых тяг» на дедушкином Москвиче, т.е. текущий ремонт, если другими словами, но и капитальный ремонт оборудования и агрегатов, с полным выводом их из эксплуатации на время ремонта. Даже если результаты мониторинга будут показывать, что все ок, то все равно будет выполнен капремонт с регламентированной заменой и/или дефектовкой всего перечня оборудования.
Данная статья, у любого асутпшника, вызывает удивление, улыбку и недоумение. Все описанные «кейсы» существуют со времен царя Гороха. Сбор данных с многих тысяч (в буквальном смысле) датчиков? Анализ ПДК? Моделирование ТП на основании текущих показателей, исторических значений или внешних возмущений? Все это давно и давно используется и накоплена неисчисляемая уйма решений. Всего-лишь еще один контроллер в полку десятки и сотен контроллеров. И вместо вот этой вот воды, лучше бы написали, почему стоит выбрать данное решение, а не какой-нибудь Сименс, Шнайдер, Митсубиси, Адам/ИспДас (прости господи, но зато за копейки). Рассказали, как обстоят дела с интеграцией в существующие системы, как оно поддерживается популярными SCADA. И главное понимать, что описанная «IoT» — это обычная АСУ ТП, но, видимо, АСУ ТП продавать сложнее, чем хайповый «интернет вещей».
Это не просто машинный перевод — это ужасный машинный перевод без последующего прочтения переведенного текста: "они не сравнятся с наушниками-вкладышами или наушниками-вкладышами".
Собственно к уже накиданному и возникает основная претензия — из-за закрытого кода совершенно не понятно, что именно там накидано. Вообще есть планы по открытию кода?
"1920х1080… разрешение является самым оптимальным на сегодняшний день" на это можно ответить только цитатой из одного хорошего фильма: "это вам кто-нибудь сказал, или вы сами решили?".
Так и не понял, почему это настолько плохая идея, что достойна отдельной статьи. Даже сам автор говорит о том, что существует некоторые области, где визуальные средства используются весьма интенсивно. Например, можно вспомнить промышленную автоматизацию, где визуальные инструменты достаточно востребованы — LD, FBD, SFC, которые спокойно (как правило) траслируются в IL/ST, что вполне решает проблему контроля версий, упомянутую автором статьи. Визуальные средства программировани имеют богатую историю, они проверены временем и они дают на выходе стабильно функционирующие ТП, уменьшая количество ошибок, которые могут быть допущены в процессе разработки, фактически сводя их только к логическим ошибкам. Но видимо эта сфера очень далека от автора, раз в пример от приводит Scratch.
И слава богу, ведь значительно быстрее воспользоваться клавиатурой, чем елозить мышкой или тачпадом.
Есть явный недостаток у такого подхода — нужно заранее знать либо имя команды… и ее имя далеко не всегда очевидны.
Можно пример такой неочевидности, пример такой команды или действия, которые бы не находились через Cmd-Shift-P по ее очевидному названию?
Часто нужно вставить какой-нибудь хитрый символ, например, стрелку или дробь
Как часто? Раз в неделю? Раз в месяц? Зачем это должно быть в редакторе кода, если оно может быть реализовано в виде плагина? Кому нужно часто вставлять юникод в коде — тот поставит плагин или просто нажмет ctrl-cmd-space для вызова системного popover. Тащить это в сам редактор кода — это странно. Хотя, разумеется, это имхо.
Простите, но при поверхностном прочтении статьи большинство «недостатков» Sublime выглядит как попытка убедить читателя, что мягкое лучше теплого, а местами и вовсе как обычная вкусовщина, ведь многим Sublime полюбился именно потому, что в нем все сделано так, как сделано — есть удобнейшая палитра команд, нет тулбаров, минимальный статус-бар, отсутствие плавающих окон, отсутствие которых порадовало после TextMate и обычные json для настройки всего и вся.
Что непонятно? Все предельно понятно, если посмотреть ассортимент этой известной компании и затем сравнить его с тем, что имеется у замечательной компании Рубетек. Найдите 10 различий. Например: 1 и 1, 2 и 2 и далее по списку. Очень жаль, что людям непонятны такие просты вещи или просто лень посмотреть на сертификат, чтобы понять кто на самом деле это делает, проектирует и производит. Ну а потом попробовать этот первосортный Китай и искать более адекватные решения для создания своего надежного и хорошего умного дома.
Оумуамуа?
Бесконечный скролл - это только половина зла, а вот полное всеобъемлющее зло наступает тогда, когда на странице еще есть некий footer с важной информацией, до которого пытаешься "домотать".
Вы еще вспомните тех чрезвычайно богатых типов, которые залезли в бочку и нырнули на 3+ километров, хотя даже школьный курс физики подсказывает, что бочка, да еще и из совершенно разных материалов - это не самая оптимальная форма для больших глубин.
А что там с сезонностью? А то, знаете, лето - время строительства.
Эх, как-то совершенно бездуховно что ли. А ведь можно было попросить какой-нибудь ChatGPT написать скрипт, который бы мониторил Google Drive, брал из него новый файл, выдергивал из него данные, вставлял в svg-шаблон, затем через какой-нибудь cairosvg конвертировал в pdf с последующей растеризацией через ghostscript, и отсылал полученный результат на указанную в файле почту.
Ну наконец-то, хоть один день в неделю буду отдыхать.
Ну, как говорится, не все так однозначно. Вот взять "огромное количество сред разработки" - не такое и огромное, если сравнивать с количеством web-фрейворков на JS, где каждый день выходит новый, с очередной революционной (той или иной степени) идеей. Да и урезанность ЯП в этой сфере - вещь относительная, ведь задачи на нижнем уровне, как правило, весьма однотипные, а если данные ушли наверх, то там уже делай с ними что хочешь и с помощью чего хочешь (порой даже за гранью добра - однажды видел развесистую статистическую систему, написанную на Visual Basic, которую тащили на своем горбу с середины 90-х). Но зачастую этого и не требуется, т.к. большинство задач вполне решаются в рамках выбранной экосистемы того или иного производителя, собрав простыню из FBD на десяток-другой экранов. Отсутствие разделения труда - тоже спорно. К примеру, еще лет 20 назад, когда я занимался АСУ ТП, у нас была четкая дифференциация штанов: монтажники, электрики, электронщики, наладчики, КИПиА, проектировщики, и отдельной кастой шел отдел инженеров и прочих программистов. Возможно, что в небольших компаниях еще можно встретить "фулл-стек" мастеров от АСУТП - от монтажных работ по пояс в нечистотах, до разработки драйверов какого-нибудь эзотерического оборудования (впрочем, и тут, скорее всего, придется работать в поле, т.к. железо будет в работе и никто не даст его для экспериментов в стерильную лабораторию). Но сомневаюсь, что в этом случае будет высокая производительность труда. Впрочем, возможно, что мне просто повезло с компанией (а точнее с региональным подразделением, где у нас уже тогда была и удаленка, и относительно свободный график, и машина с водителем, и бильярдная со штангой, и даже чайник с безлимитными печенюшками и 3-х литровой банкой заварки - все те "блага", которые лишь потом стали "стандартом" отрасли). Тем не менее, проблема разделения и условий труда решаема в пределах той или иной организации, было бы желание. Тоже самое касается качества кода и его сопровождения. 20 лет назад уже использовалась CVS везде, где можно было экспортировать в текстовый вид, а где нельзя - просто бинарными файлами, что при наличии документации и качественного комментирования коммитов давало хоть какое-то версионирование и уверенность в завтрашнем дне. Особенную радость в то время вызвало появление Tortoise CVS и затем SVN - даже проектантов удалось перетащить c VSS. Да и связь между удаленными офисами кое-как наладили, пусть и с ограничениями того времени - модемы на отправку, спутник на прием, ну и более-менее быстрый (по меркам того времени) Интернет как бонус. Поэтому
чисто там, где не мусоряткультура разработки есть там, где ей уделяют должное внимание. Ну а что касается открытых решений, то тут не поспоришь - как вспомню написание OPC гейтвейта, без возможности купить стандарт и имея под рукой только тулзу для тестирования интерфейсов OPC, так аж нехорошо становится. Но нужно ли это производителям ? Вот это вопрос.Экологичнее - это факт. Еще бы им не быть экологичнее, если к ним прикручены рециркуляции, рекуперации, катализаторы и прочие сажевые фильтры. Но вот то, что они стали сильно меньше расходовать топлива, а главное - стали дешевле в производстве - это не так очевидно. 20 лет назад я на универсале (Пассат Б3 с 1.6) по трассе укладывался в 6-7 литров на сотню, что сейчас схожие по размеру машины с похожим объемом двигателя кушают по 5-6 литров. Разница есть, но без вау эффекта. Но там, простите, был совершенно примитивный двигатель с самым обычным моновпрыском. Сейчас мы имеем двигатели с распределенным впрыском, насос-форсунками, работающие на более высокой степени сжатия, имеющими более сложный обвес (по сравнению с тем древним моновпрыском, которому для работы было нужно 3 датчика). Не уверен, что современный двигатель будет дешевле в производстве. Поэтому если и видно развитие, то только в сторону получения более высоких показателей при одновременном повышении экологичности, но скорее всего в ущерб стоимости.
Ммм, и давно 2600 км стало смерти подобно для обычного человека? За сутки, разумеется, нереально - из подобий автобанов у нас, на вскидку, могу назвать только Москва-Питер, где можно без нарушений ехать 130, но 1300 км легко проезжаются за световой (с небольшим захватом рассвета-сумерек) день в расслабленном темпе и по обычным трассам. По крайней мере в левой части глобуса России, где есть нормальная дорога от Баренцева до самого Черного моря, спокойно проезжаемая (по своему опыту) за 3 дня - умываемся на побережье Баренцева моря, день до Питера, день до Воронежа и глубоким вечером на 3 день вы уже моете сапоги в Черном море. Соглашусь, что такие поездки нужны не всем, да и чаще чем 2-3 раза в год вряд ли востребованы, но само осознание возможности такой свободы и независимости в передвижении дорого стоит. Собственно, разве автомобиль и не создан ради такой свободы? Поэтому остается только ждать революции-эволюции возможности аккумулировать больше энергии и заливать ее в аккумуляторы через проводники разумного сечения.
Думал зайти, написать о том, как же утомили ежедневные посты (и это на профильном ресурсе, где находятся те, кто уже так или иначе там) про то, как войтивайти не вставая с дивана, а тут, наконец-то, дельная информация.
Другое дело КП, когда по совокупности накопленного износа (или даже других факторов, на которые мы не можем повлиять никакими измерениями, например фактором сезонности, контрактных или гарантийных обязательств) основного оборудования нет возможности продолжать работу без полной остановки ТП и/или переходе на резерв. Иногда сроки КП можно отодвинуть на основании текущих показателей, но иногда это невозможно, даже если все показатели в норме. Примеров можно привести массу, к примеру, возьмем какой-нибудь турбодетандер разложения воздуха, допустим Ротофлоу, который устанавливается поставщиком и для обслуживания которого у нас нет ни квалификации, ни опыта (или как сейчас модно говорить — экспертизы). Согласно обязательствам срок службы агрегата 5 лет (условно), а значит, хотим мы этого или нет, но через 5 лет либо приедет фура с новым турбодетандером и он будет заменен целиком, либо будет произведен КП по месту.
Данная статья, у любого асутпшника, вызывает удивление, улыбку и недоумение. Все описанные «кейсы» существуют со времен царя Гороха. Сбор данных с многих тысяч (в буквальном смысле) датчиков? Анализ ПДК? Моделирование ТП на основании текущих показателей, исторических значений или внешних возмущений? Все это давно и давно используется и накоплена неисчисляемая уйма решений. Всего-лишь еще один контроллер в полку десятки и сотен контроллеров. И вместо вот этой вот воды, лучше бы написали, почему стоит выбрать данное решение, а не какой-нибудь Сименс, Шнайдер, Митсубиси, Адам/ИспДас (прости господи, но зато за копейки). Рассказали, как обстоят дела с интеграцией в существующие системы, как оно поддерживается популярными SCADA. И главное понимать, что описанная «IoT» — это обычная АСУ ТП, но, видимо, АСУ ТП продавать сложнее, чем хайповый «интернет вещей».
Можно пример такой неочевидности, пример такой команды или действия, которые бы не находились через Cmd-Shift-P по ее очевидному названию?
Как часто? Раз в неделю? Раз в месяц? Зачем это должно быть в редакторе кода, если оно может быть реализовано в виде плагина? Кому нужно часто вставлять юникод в коде — тот поставит плагин или просто нажмет ctrl-cmd-space для вызова системного popover. Тащить это в сам редактор кода — это странно. Хотя, разумеется, это имхо.
Простите, но при поверхностном прочтении статьи большинство «недостатков» Sublime выглядит как попытка убедить читателя, что мягкое лучше теплого, а местами и вовсе как обычная вкусовщина, ведь многим Sublime полюбился именно потому, что в нем все сделано так, как сделано — есть удобнейшая палитра команд, нет тулбаров, минимальный статус-бар, отсутствие плавающих окон, отсутствие которых порадовало после TextMate и обычные json для настройки всего и вся.