Здравствуйте, landerhigh, Вы писали:
L>>>Как ты думаешь, сколько типов датчиков поддерживает одна наиболее используемых в мире SCADA систем в мире? BFE>>Думаю, что сколько бы не поддерживали у них у вех унифицированный протокол обмена. А что? L>В общем, да. Только этих протоколов одних несколько сотен, если говорить о сколько-нибудь унифицированных хотя бы их производителем. Не говоря уже о вариантах каждого из них. L>Даже industry standard протоколы существуют в нескольких вариантах, и при этом каждый производитель умудряется по-своему понять определенные пункты стандарта
Ok. И вы хотите сказать, что написание тестов перегрузки входными данными для всех комбинаций этого зоопарка заняли меньше времени, чем написание самого кода? Или у вас всё поверх IP написано?
И каждый день — без права на ошибку...
Re[29]: Долгая компиляция на с++ - смерть для больших проект
Здравствуйте, Erop, Вы писали:
BFE>>Кстати, можете предложить не инвазивный способ тестирования? E>RAM-диск с драйвером, позволяющим эмулировать проблемы...
Да, это хороший вариант, недорогой.
И каждый день — без права на ошибку...
Re[32]: Долгая компиляция на с++ - смерть для больших проект
Здравствуйте, B0FEE664, Вы писали:
BFE>Ok. И вы хотите сказать, что написание тестов перегрузки входными данными для всех комбинаций этого зоопарка заняли меньше времени, чем написание самого кода? Или у вас всё поверх IP написано?
Нам не нужно весь зоопарк тестировать. Только тот, который имеет возможность вызвать перегрузку. Для железа, до сих пор работющего по RS485, да на низком рейте, это почти нереально.
А вот для IP-based протоколов таки да. Там, где симуляторы были доступны (или написаны нами) симуляция перегрузки тривиальна. Там, где нет, ее можно эмулировать наиболее удобным для нас способом.
Только вот такой момент — нам не нужно тестировать нагрузочную способность всей системы, так как нагрузочные способности ее частей известны и тестируются по отдельности. Нам нужно было гарантировать то, что поддержка каждого нового протокола не имеет в себе бутылочного горлышка и что она не упадет при выросшем количестве сообщений в секунду.
Re[32]: Долгая компиляция на с++ - смерть для больших проект
Здравствуйте, Erop, Вы писали:
L>>Юнит тесты должны проверять четко формализованные критерии. E>Бинго! Есть КУЧА ПО, критерии на который плохо поддаются формализации E>Например, "Хорошая игрушка", "удачная стиральная машина", "лучшая в мире система ПВО" и т. д...
Никакое это не бинго. Речь о том, что даже ясную, простую и достаточно формальную задачу о тексте внутри кнопки невозможно протестировать, так как размер текста зависит от внешнего ресурса — шрифта, который может быть произвольным. Речь не идёт о прилагательных "хорошая", "удачная", "лучшая"...
И каждый день — без права на ошибку...
Re[19]: Долгая компиляция на с++ - смерть для больших проект
Здравствуйте, __kot2, Вы писали:
__>дебагер это как бы такая скрипучая телега со старой лошадью. да, иногда можно выгнать ее из стойла, смахнуть пыль и даже куда-то поехать, но это просто несерьезно. дебагер хорош только если вы вообще никуда не торопитесь и вам просто нравится копаться в коде. если у вас в реальной жизни дошло дело до дебагера, значит, вы делаете что-то очень и очень неправильно.
__>то есть транспортная компания конечно может держать резервную лошадь с телегой в стойле и даже целую конюшню, но я бы лично не стал не хотел бы работать с тем, кто будет на этом настаивать и рассказывать о всех преимуществах лошади над машинами и дронами
__>вообще, я иногда пишу код без тестов, оосбенно если это прототип. но когда он начинает выдавать неожиданные результаты, или я просто хочу убедиться в корректности результата, я не лажу в дебагере на конкретных примерах. это глупо. это просто трата своего времени впустую. я беру пишу минимальные тестовые примеры и тесты. то же самое, что кто-то другой будет делать руками, я сделаю автоматом. при этом так как я знаю, как писать код для тестов, мне не понадобится для этого ничего особо переписывать, код сразу готов в ним.
Я вот не могу понять откуда такая ненависть к дебагеру. И если вы не любите или не умеете пользоваться дебагером, можете просто не пользоваться им (хотя рекомендую научиться, ингда может сильно облегчить жизнь), зачем пытаться всем доказать, что дебагер вреден.
И как вообще тесты могут его заменить? И почему вообще тесты должны заменять дебагер? Тесты и дебагер выполняют разные функции:
Тесты проверяют, что код делает именно то, что требуется.
Дебагер помогает понять, что именно делает код в реальности.
Одно другому никак не мешает.
Re[33]: Долгая компиляция на с++ - смерть для больших проект
Здравствуйте, B0FEE664, Вы писали:
BFE>Никакое это не бинго. Речь о том, что даже ясную, простую и достаточно формальную задачу о тексте внутри кнопки невозможно протестировать, так как размер текста зависит от внешнего ресурса — шрифта, который может быть произвольным. Речь не идёт о прилагательных "хорошая", "удачная", "лучшая"...
UI с юнит-тестами вообще не особо дружит. Чисто идеологически.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[34]: Долгая компиляция на с++ - смерть для больших проект
Здравствуйте, Erop, Вы писали:
BFE>>Никакое это не бинго. Речь о том, что даже ясную, простую и достаточно формальную задачу о тексте внутри кнопки невозможно протестировать, так как размер текста зависит от внешнего ресурса — шрифта, который может быть произвольным. Речь не идёт о прилагательных "хорошая", "удачная", "лучшая"...
E>UI с юнит-тестами вообще не особо дружит. Чисто идеологически.
Равно как "произвольный шрифт" к "хорошему UI" тоже особо не относится.
Re[35]: Долгая компиляция на с++ - смерть для больших проект
Здравствуйте, landerhigh, Вы писали:
L>Равно как "произвольный шрифт" к "хорошему UI" тоже особо не относится.
А язык, на который переведут программу когда-нибудь?..
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[35]: Долгая компиляция на с++ - смерть для больших проект
Здравствуйте, landerhigh, Вы писали:
L>Равно как "произвольный шрифт" к "хорошему UI" тоже особо не относится.
Это ещё почему? Ровно наоборот: у людей разные вкусы, разные мониторы, разные предпочтения цветовой гаммы и разное зрение. Кто-то не может без clear type, а кто-то его ненавидит. Поэтому хороший UI должен быть подстраиваться под конкретного пользователя. А это, в числе прочего, предполагает и выбор подходящего шрифта.
И каждый день — без права на ошибку...
Re[36]: Долгая компиляция на с++ - смерть для больших проект
Здравствуйте, B0FEE664, Вы писали:
L>>Равно как "произвольный шрифт" к "хорошему UI" тоже особо не относится.
BFE>Это ещё почему? Ровно наоборот: у людей разные вкусы, разные мониторы, разные предпочтения цветовой гаммы и разное зрение. Кто-то не может без clear type, а кто-то его ненавидит. Поэтому хороший UI должен быть подстраиваться под конкретного пользователя. А это, в числе прочего, предполагает и выбор подходящего шрифта.
Вот на что я не занимаюсь UI, но прекрасно знаю, что для чтения с экрана подходит не то, что юзер в данный момент "предпочитает", а весьма ограниченный выбор типов шрифтов. Не говоря уже о цветовой гамме.
Только в любом случае это задача дизайнера.
Re[37]: Долгая компиляция на с++ - смерть для больших проект
Здравствуйте, landerhigh, Вы писали:
L>>>Равно как "произвольный шрифт" к "хорошему UI" тоже особо не относится. BFE>>Это ещё почему? Ровно наоборот: у людей разные вкусы, разные мониторы, разные предпочтения цветовой гаммы и разное зрение. Кто-то не может без clear type, а кто-то его ненавидит. Поэтому хороший UI должен быть подстраиваться под конкретного пользователя. А это, в числе прочего, предполагает и выбор подходящего шрифта. L>Вот на что я не занимаюсь UI, но прекрасно знаю, что для чтения с экрана подходит не то, что юзер в данный момент "предпочитает", а весьма ограниченный выбор типов шрифтов. Не говоря уже о цветовой гамме.
Это заблуждение. Я думаю, что мне даже понятна психологическая составляющая неприятия разнообразия UI. Это неприятие отражено, например в этой вашей фразе:
Даже industry standard протоколы существуют в нескольких вариантах, и при этом каждый производитель умудряется по-своему понять определенные пункты стандарта
Употребление слова "умудряется" свидетельствует о негативном отношении к разнообразию, что, несомненно, положительное качество для человека разрабатывающего системы производственного контроля. Но у него есть и оборотная сторона. В частности — отрицание того, что разным людям удобно работать с разными размерами шрифта. Люди с выраженной миопией предпочитают мелкий шрифт, а люди с дальнозоркостью — большой размер шрифта. У последних будет болеть голова, если они будут работать со шрифтами настроенными для человека с миопией.
L>Только в любом случае это задача дизайнера.
Дизайнеры будут программировать способы отрисовок и размеры кнопки? Или, может, дизайнеры понимают требования к шрифту для программистов?
Не знаю как сейчас, я давно не занимаюсь UI, но лет 10 назад дизайнеры даже близко не понимали проблем и задач связанных с хорошим интерфейсом пользователя.
И каждый день — без права на ошибку...
Re[38]: Долгая компиляция на с++ - смерть для больших проект
Здравствуйте, B0FEE664, Вы писали:
BFE>Это заблуждение. Я думаю, что мне даже понятна психологическая составляющая неприятия разнообразия UI. Это неприятие отражено, например в этой вашей фразе: BFE>
BFE>Даже industry standard протоколы существуют в нескольких вариантах, и при этом каждый производитель умудряется по-своему понять определенные пункты стандарта
BFE>Употребление слова "умудряется" свидетельствует о негативном отношении к разнообразию,
BFE>что, несомненно, положительное качество для человека разрабатывающего системы производственного контроля. Но у него есть и оборотная сторона. В частности — отрицание того, что разным людям удобно работать с разными размерами шрифта.
А вот нифига. Покажи мне пограммиста, которому было бы удобно работать с кодом, отображающимся не-моноширинным шрифтом.
L>>Только в любом случае это задача дизайнера. BFE>Дизайнеры будут программировать способы отрисовок и размеры кнопки? Или, может, дизайнеры понимают требования к шрифту для программистов?
Дизайнеры размещают кнопки и обеспечивают читаемость и понятность текста на них. Это не задача программиста.
Re[39]: Долгая компиляция на с++ - смерть для больших проект
Здравствуйте, landerhigh, Вы писали:
BFE>> В частности — отрицание того, что разным людям удобно работать с разными размерами шрифта. L>А вот нифига. Покажи мне пограммиста, которому было бы удобно работать с кодом, отображающимся не-моноширинным шрифтом.
Я вам про размер, а вы мне про моноширинность.
от сегодняшнего числа. Легко, думаете, для такого unit test написать?
L>>>Только в любом случае это задача дизайнера. BFE>>Дизайнеры будут программировать способы отрисовок и размеры кнопки? Или, может, дизайнеры понимают требования к шрифту для программистов? L>Дизайнеры размещают кнопки и обеспечивают читаемость и понятность текста на них. Это не задача программиста.
А потом оказывается, что при разрешении 640x480 окно не влезает в экран. Плавали, знаем.
И каждый день — без права на ошибку...
Re[40]: Долгая компиляция на с++ - смерть для больших проект
Здравствуйте, B0FEE664, Вы писали:
L>>А вот нифига. Покажи мне пограммиста, которому было бы удобно работать с кодом, отображающимся не-моноширинным шрифтом. BFE>Я вам про размер, а вы мне про моноширинность.
от сегодняшнего числа. Легко, думаете, для такого unit test написать?
Отлавливать такую чертовщину — не задача юнит-тестов
L>>>>Только в любом случае это задача дизайнера. BFE>>>Дизайнеры будут программировать способы отрисовок и размеры кнопки? Или, может, дизайнеры понимают требования к шрифту для программистов? L>>Дизайнеры размещают кнопки и обеспечивают читаемость и понятность текста на них. Это не задача программиста. BFE>А потом оказывается, что при разрешении 640x480 окно не влезает в экран. Плавали, знаем.
Дизайнеры должны были предусмотреть и такое. Или ограничить минимальное разрешение.
Re[39]: Долгая компиляция на с++ - смерть для больших проект
Здравствуйте, landerhigh, Вы писали:
BFE>>разным людям удобно работать с разными размерами шрифта.
L>А вот нифига. Покажи мне пограммиста, которому было бы удобно работать с кодом, отображающимся не-моноширинным шрифтом.
1) Тип гарнитуры не размер.
2) Одно время было можно юзать шрифт, максимально ужатый по горизонтали, нифига не моноширинный...
L>Дизайнеры размещают кнопки и обеспечивают читаемость и понятность текста на них. Это не задача программиста.
А что будет, если юзер сменит шрифт/язык?
И как будет тестироваться то, что ничего не сломалось?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[40]: Долгая компиляция на с++ - смерть для больших проект
Здравствуйте, Erop, Вы писали:
L>>А вот нифига. Покажи мне пограммиста, которому было бы удобно работать с кодом, отображающимся не-моноширинным шрифтом. E>1) Тип гарнитуры не размер.
Кое-кто заявлял про произвольный шрифт.
Менять же размер шрифта, не меняя размеров всех элементов UI в общем случае задача странная.
E>2) Одно время было можно юзать шрифт, максимально ужатый по горизонтали, нифига не моноширинный...
Потому что от этого он становился моноширинным, да?
L>>Дизайнеры размещают кнопки и обеспечивают читаемость и понятность текста на них. Это не задача программиста. E>А что будет, если юзер сменит шрифт/язык? E>И как будет тестироваться то, что ничего не сломалось?
Ребята, если японской бензопилой пытаться пилить железнодорожные рельсы, то она сломается. И, кстати, в процессе можно отпилить себе ногу.
Но проблема будет вовсе не в пиле.
Re[41]: Долгая компиляция на с++ - смерть для больших проект
Здравствуйте, landerhigh, Вы писали:
L>>>А вот нифига. Покажи мне пограммиста, которому было бы удобно работать с кодом, отображающимся не-моноширинным шрифтом. BFE>>Я вам про размер, а вы мне про моноширинность. L>А я про моноширинность, да.
Ну и причём тут моношеринность? Вы используете моноширинный шрифт для текста в кнопках?
BFE>>Вот, кстати, пример
от сегодняшнего числа. Легко, думаете, для такого unit test написать? L>Отлавливать такую чертовщину — не задача юнит-тестов
Ну вот. Как дошло до практики, так — незадача.
L>>>>>Только в любом случае это задача дизайнера. BFE>>>>Дизайнеры будут программировать способы отрисовок и размеры кнопки? Или, может, дизайнеры понимают требования к шрифту для программистов? L>>>Дизайнеры размещают кнопки и обеспечивают читаемость и понятность текста на них. Это не задача программиста. BFE>>А потом оказывается, что при разрешении 640x480 окно не влезает в экран. Плавали, знаем. L>Дизайнеры должны были предусмотреть и такое. Или ограничить минимальное разрешение.
Вы знакомы хотя бы с одним таким дизайнером?
И каждый день — без права на ошибку...
Re[42]: Долгая компиляция на с++ - смерть для больших проект
Здравствуйте, B0FEE664, Вы писали:
L>>А я про моноширинность, да. BFE>Ну и причём тут моношеринность? Вы используете моноширинный шрифт для текста в кнопках?
от сегодняшнего числа. Легко, думаете, для такого unit test написать? L>>Отлавливать такую чертовщину — не задача юнит-тестов BFE>Ну вот. Как дошло до практики, так — незадача.
Совершенно верно. Прочитай уже определение юнит-теста, что ли.
L>>Дизайнеры должны были предусмотреть и такое. Или ограничить минимальное разрешение. BFE>Вы знакомы хотя бы с одним таким дизайнером?
Я не занимаюсь UI, но когда придется этим заниматься, работать с профнепригодными дизайнерами не буду ни минуты.
