АСУ ТП в облаке — быстрая разработка проектов

[Владимир Ситников]

Я тоже сначала увлекался циклами и косвенной адресацией, но иногда после тебя этот код будут смотреть и дополнять/править/ругать еще и наладчики. Вот зачем им на объекте эти качели?

"что за нахи" всё равно будут: http://commadot.com/wtf-per-minute/

Можно всё-таки увидеть какой-нибудь пример?
"Была задача такая-то", "обычно решается так-то", "предлагается решать так-то", "экономия на разработке -- 10 дней", "экономия на поддержке -- 20 дней", "затраты на доп обучение -- 15 дней", "затраты на программиста -- 25 дней"

Вот классика жанра на тему автоматизации: https://www.youtube.com/watch?v=5Qn9...outu.be&t=4170

[Владимир Ситников]

не используйте устаревший класс стрингбуффером, используйте стрингбильдер

Вообще говоря, претензия не обоснована.
Я ни разу не встречал случаев, когда замена StringBuffer на StringBuilder хоть как-то улучшила производительность (ну так, чтобы клиент заметил).
"Сложение в цикле без String**er" -- такое, да, часто. Но вот чтобы Builder vs Buffer -- ни разу.

Вот материал по теме: http://shipilev.net/talks/jpoint-Apr...-catechism.pdf, https://youtu.be/YgGAUGC9ksk?t=462

И, да, в java9 вообще переделают компиляцию string+string, т.е. там явное использование String*** может оказаться медленнее, чем простое сложение строк (разумеется, вне циклов).

Поэтому и говорил про контекст, нужна потокобезопасность или нет. А вообще спасибо, я хоть немного в памяти всё это освежил))

Мне ни разу не встречался случай, когда нужно многопоточно складывать строку. Если такое кто-то напишет, его тут же расстреливать нужно.
Поэтому, аспект "synchronized" рассматривать при сложении строк это последнее дело.

"контекст" может иметь следующе право на жизнь: пользуемся сторонней библиотекой, и она, собака, требует StringBuffer как один из аргументов. Ну, тут придётся использовать StringBuffer и на Builder никак не заменить.

Но это всё лирика. Не понимаю, как Builder vs Buffer может относиться к АСУТП.
Блин. Я уже знаю как АСУТП пишется, и понятия не имею что оно значит )

[krollcbas]

Кстати вот, вспомнил. Идеи создать что-либо более оптимальное для создания проектов уже разрабатывались, но спотыкались на внедрении
SimInTech от 3В-технологии
http://www.remmag.ru/admin/upload_da...9-3/3VTech.pdf

Вот к примеру был автоматом создан проект какой-либо умной софтиной, допустим есть экономическая выгода.
Что тогда делать службе эксплуатации, так же покупать этот софт для корректировки (например датчик добавили)?

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

[capzap]

Гуляю сам по себе исключительно. АСУТП занимаюсь последние лет 10.


Циклы это конечно здорово, и я сам бы тоже самое написал, когда начинал заниматься промышленной автоматизацией. Но потом понял, что для систем, которые постоянно переделываются/совершенствуются/дополняются это не есть хорошо. Потому как код должен быть понятен человеку "почти что с улицы", а править желательно на ходу, не отправляя контроллер в стоп. И подобный говнокод используется в частности тут:




ЗЫ: Вспомнил пример интегрированной среды разработки у АВВ Там вообще все интересно - контроллер программируется через SCADА. Ни у кого больше такого не видел.

что Вы хотели сказать этим видео, начнем с банального: моя твоя не понимать

а в принципе, я пока не увидел эффективности в построчном описании каждого объекта. Вот Вы пишите

код должен быть понятен человеку "почти что с улицы"

, другими словами ему должно быть понятно, что в "портянке" из тысячи однотипных строк (а у Вас в примере на обработку клапана ушло 8 строк, значит умножаем на восемь) у него всё в полном порядке и почему это должно быть более понятным, чем всё тоже самое в цикле занимающем всего 10 строк, они так то для этого и придуманы и в стороннем ПО будет делаться тоже самое

[capzap]

Наверное опять подумают, что мы сговорились, но снова соглашусь.
Я тоже сначала увлекался циклами и косвенной адресацией, но иногда после тебя этот код будут смотреть и дополнять/править/ругать еще и наладчики. Вот зачем им на объекте эти качели?
Им надо взять код и сразу все понять и поправить.

в чем качели, либо Вы спасаете программиста от рутинной работы ускоряя процесс копипастинга однотипных операций, а это значит если в коде объекта у Вас ошибка, то это касается всех объектов, если это какая то индивидуальная особенность одного из множества объектов, то его в цикле не обработаешь ни в самом проекте, не с помощью внешних вспомогательных ПО

[qs212]

что Вы хотели сказать этим видео, начнем с банального: моя твоя не понимать

Было где то дельное видео по этому продукту, но я его к сожалению сейчас не нашел. Эта система есть надстройка над симатиком или рс лоджиком, сильно ускоряющая процесс проектирования. На ней даже в России построены десятки заводов. Ну это так, к слову.

а в принципе, я пока не увидел эффективности в построчном описании каждого объекта. Вот Вы пишите, другими словами ему должно быть понятно, что в "портянке" из тысячи однотипных строк (а у Вас в примере на обработку клапана ушло 8 строк, значит умножаем на восемь) у него всё в полном порядке и почему это должно быть более понятным, чем всё тоже самое в цикле занимающем всего 10 строк, они так то для этого и придуманы и в стороннем ПО будет делаться тоже самое

Все верно. А теперь представьте себе, что нужно отрезать часть оборудования, к примеру процентов 20. И время на остановку дается пару раз по пару часов, чтобы переконфигурировать сеть. . В данном случае закомментировал ручками, вгрузил и вперед, разбирать. И ресурсы в контроллере без проблем освободились.

[Владимир Ситников]

ну я же уже писал, что решил проверить насколько Вы способны писать профессиональный код.

Вообще говоря, закодировать это самое простое.
Гораздо сложнее понять что именно нужно кодировать. И понять "нужно ли". А для этого нужна экспертиза, которая, в конкретном случае, может с программированием мало чего общего иметь.

Вон, если окажется, что продукт нужен, то, может и команда набраться. Из тех, кто умеет ролики снимать (а как же без документации?), и из тех, кто программировать умеет.

Вот поэтому у меня и сложилось впечатление, что человек пытающийся предложить автоматизацию программирования, не пользуется возможностями среды разработки

Если в контексте "человек не пользовался автоматизацией, которую предлагают Java IDE, а значит, он и в АСУ ТП автоматизации ничего не понимает", то, может, что-то в этом и есть.
Но, по-моему, это как-то уж слишком далеко идущие выводы. В конце концов, изначальный вопрос задавался далеко не про Java.

на скрине сразу подчеркивается что стоит заменить буффер на билдер и верю разработчикам нетбинса больше чем Вам

Если говорить про конкретное "подчёркивание", то в 99.9999% случаев вы вообще никак не ощутите разницу скорости StringBuilder и StringBuffer.
Поэтому так напирать на Buffer и Builder крайне и крайне странно.

Ещё раз: если рассматривать с точки зрения "новичка", то, безусловно, невежественно игнорировать подсказки IDE. Но мы-то тут не на java программировать учимся. А, с точки зрения опытного разработчика, тыкать в Builder vs Buffer нехорошо.

верю разработчикам нетбинса больше чем Вам

В производительность не нужно верить. Её нужно измерять.
Вот вам пример на эту же тему (~рекомендация среды): http://shipilev.net/blog/2016/arrays...ents/#img-idea

Вообще все кому не лень рекомендуют вместо collection.toArray(new Foo[0]) использовать collection.toArray(new Foo[collection.size()]).
Интуитивно кажется, что рекомендация хорошая (сразу создаём массив нужного размера). Но реальные замеры показывают, что такая замена только ухудшает производительность.

И, да, Лёша Шипилёв это один из инженеров по производительности Oracle JDK. Т.е. он не просто "кто-то с горы", а тот, кто напрямую занимается производительностью Oracle Java.

[capzap]

Все верно. А теперь представьте себе, что нужно отрезать часть оборудования, к примеру процентов 20. И время на остановку дается пару раз по пару часов, чтобы переконфигурировать сеть. . В данном случае закомментировал ручками, вгрузил и вперед, разбирать. И ресурсы в контроллере без проблем освободились.

Вы будете комментировать 20% строк кода? давай те посмотрим на мой подход к такой реализации, я в теле цикла ставлю условие или кейс, где исключаю обработку не задействованных на данный момент объектов, ну максимум четыре строки придется добавить, что скажите?

[qs212]

Вы будете комментировать 20% строк кода? давай те посмотрим на мой подход к такой реализации, я в теле цикла ставлю условие или кейс, где исключаю обработку не задействованных на данный момент объектов, ну максимум четыре строки придется добавить, что скажите?

20% то зачем? Закоментировать нужно строку с вызовом функции.
Скажу, что если то, что нужно удалить идет не подряд, а как попало, то это будет не весело.

[Владимир Ситников]

при чем тут пользователь

При том, что именно пользователь определяет границу, когда "тормозит", а когда "удовлетворительно быстро работает".
Это называется нефункциональные требования на производительность.

Пользователю вообще без разницы говнокод или нет. Тому, кто поддерживать будет, конечно, говнокод не очень нравится.
Но оптимизировать можно бесконечно. Просто нужно вовремя остановиться, и начать тратить время на более продуктивные занятия.

что говорит элементарный профилировщик, понятно что одно использование будет показывать минимальную единицу времени, а ту же самую тысячу использований?

Так я же ссылку показывал: http://shipilev.net/talks/jpoint-Apr...-catechism.pdf, слайд 16.

Цитирую слайд:

public String stringBuilder() {
  StringBuilder sb = new StringBuilder();
  for(int c = 0; c < 1000; c++) {
    sb.append ("Bar");
  }
  return sb.toString ();
}

Buffer:  125270 операций/сек
Builder: 116173 операций/сек
String+String: 3250 операций/сек

(одна операция -- 1000 сложений)

Во-первых Buffer быстрее ¹
Во-вторых, даже если Лёша опечатался и перепутал, то разница мизерная.

Переведу с русского на русский: за одну секунду StringBuffer успевает построить строку длинной 125270*1000*3=375'810'000, а StringBuilder -- строку длинной 116173*1000*3=348'519'000 символов.
Для сравнения, если цикл сделан без Builder/Buffer, а по-крестьянски складываются строки, то удаётся сгенерировать всего 3250*1000*3=9'750'000 символов.

Если в реальной задаче действительно возникает потребность создавать _так много_ строк, то наверняка будет ещё более эффективное решение, чем эти builder/buffer'ы (например, распараллеливать задачу между несколькими вычислительными потоками)

¹ Разумеется, всё может сильно зависеть от модели процессора, от версии java, от характера складываемых строк.
Но, блин, так напирать на Builder это жесть просто. Нету там разницы. Нету.