Вы используете российский газ — вы ватник?

Пока нет альтернатив — ещё нет. Если за два года не откажемся — значит, ватники.

Вы используете российское ядерное топливо — вы ватник?

Безусловно. Пора заново запускать добычу в Жёлтых Водах.

Вы заливаете российский бензин на заправках с украинскими флагами — вы ватник?

На Лукойле или ТНК — да, ватник. На остальных — по обстановке.

Вы выбросили из дому все вещи, сделанные в России?

Назовите такую вещь, я подумаю.

Что за вброс?

Вы вбрасываете — вот и ответьте.

Это, кстати, вряд-ли — везде пишут, что классы питона — это не классы .net-а.

И чем это мешает таким вызовам?

Например, я могу получить обьект .net-овского класса и поиграться в его свойствами с помощью getattr и setattr

И delattr:) Нет, такие игры, конечно, интересны. Только для интеграции кода они значат менее 1%

Вообще-то ironpython — это под windows.

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

Чуть не забыл — возможно, вы щупали ранние версии питона, до 2.6 и под ранний .net, до 4.

Как раз был 2.6.

Сейчас ironpython основан на .net 4 минимум, там есть какой-то dlr, который и дает все фишки питона на .net-е.

Это в смысле — обратные вызовы — питоновский код из произвольного дотнета? Если да, это ничем не поможет.

Теперь они отвечают за всё.

В размере 5$, как обычно?

ISO 900x на самом деле не стандарт качества, как его преподносят, это стандарт ПОВТОРЯЕМОСТИ КАЧЕСТВА РЕЗУЛЬТАТА.

Если ещё точнее, это стандарт документирования рабочих процессов так, что при их буквальном исполнении будет повторяемость качества результата.

Осталось найти, где «у нас» буквально исполняют циркуляры и соблюдают нормативы.

Но за последнюю декаду аутсорс превратился в business as usual.

Автор текста излишне англизирован: в русском «декада» — 10 дней, а не лет.

В остальном в значительной мере согласен.

Linux duzhe pagano viglyadaye.

Це тому у Вас немає кирилічної розкладки?:) Мабуть, тільки в Винді треба вистебнутись через ліве вухо сусіда, щоб зробити банальність — активувати «фонетичну» розкладку.

Donedavna navit’ zglazhuvann’ya shriftiv ne bulo normal’nogo.

В мене юніксовий десктоп з 97-го, і ніколи не було проблем з тим, що десь шрифти незглажені. Це зглажування — якийсь дивний жупел, яким всі розмахують, але не бачать різниці в реальних застосуваннях.

A sche na Linuxi nemaye klienta Google Drive ))

Якого саме клієнта? Є драйвер для FUSE, що дозволяє монтувати Google Drive як локальную FS:) Чи мова про окремий гуйовий застосунок? Такого, може, й нема, тому що користі в ньому нуль цілих дідько десятих:)

Если именно для работы, то вариант только один: Ubuntu

Если именно для работы, то варианта два: OpenSuSE и Debian.
Ровно такое же IMHO, зато на личном опыте большинства нашего коллектива:)

Чего-то вспомнилось:

— Заказы заказывал, материалы и оборудование использовал, отдельное помещение занимал, два года работал — и вот, нате вам, пожалуйста! — распалялся от собственных слов Хилобок. — А как он на защите-то... ведь не только меня он осрамил — меня-то что, ладно, но ведь и вас, Аркадий Аркадьевич, вас!.. Вот будь на то моя воля, Аркадий Аркадьевич, я бы этому Кривошеину за то, что он такое сотворил ухитриться... то есть ухитрил сотвориться — тьфу, простите! — сотворить ухитрился... я бы ему за это!.. — доцент навис над столом, в его карих глазах сиял нестерпимый блеск озарения. — Вот жаль, что у нас принято лишь награждать посмертно, объявления да некрологи всякие," де мортуис аут бене, аут нихиль ", понимаете ли!.. А вот вынести бы Кривошеину выговор посмертно, чтоб другим неповадно было! Да строгий! Да с занесением...

— ...на надгробие. Это мысль! — добавил голос за его спиной. — Ох, и гнида же вы, Хилобок!

Гарри Харитонович распрямился так стремительно, будто ему всадили заряд соли пониже спины. Азаров поднял голову: в дверях стоял Кривошеин.

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

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

Подставляются целевые заглушки-эмуляторы (в английском обычно используется термин mock) вместо доступа к БД и интерфейса соответствующего API.

Самый базовый комплект тестов должен определить, что необходимые методы моков вызвались в нужном порядке, и подставить вместо них положенные для теста корректные данные. При этом комплект должен быть сформирован так, чтобы было отработано максимально возможное количество веток исполнения (критерий покрытия кода — дешёвый и эффективный), в идеале — все ветки.

Расширение этого комплекта может идти в нескольких направлениях:

1. Банальное увеличение множества тестируемых вариантов на все, даже вроде бы тривиальные, случаи. В 99% случаев смысл оказывается только в очистке собственной совести (чем Ваши подчинённые не утруждают себя), зато предельно дёшев.

2. Эмуляция отказа потенциально ненадёжного участника (в указанном примере это БД — может порваться сеть по дороге, может быть переполнение соединениями, отказ диска, etc.) и проверка положенной реакции тестируемого кода на эти ситуации, даже если это банальное «мы такие исключения не ловим, нам только зачистить локально выделенные ресурсы».
Тесты такого рода необходимы для контроля надёжности системы.

3. Инверсия тестов методом искажения входных данных (выходные должны перестать соответствовать ожидаемому). Неположенное положительное прохождение теста сигнализирует или о проблемах тестовой среды, или о сложных нарушениях логики кода.
Тесты такого рода желательны в разумном (обычно небольшом) количестве и могут сходиться с пунктом 2. (У меня они срабатывали, кажется, 3 раза, и каждый раз это вскрывало серьёзную внутреннюю проблему.)

4. Рандомизированные тесты с хотя бы приблизительным предсказанием ожидаемого результата. Допустимы при условии, что тестовая среда способна при отказе теста зафиксировать точные входные данные для ручного повторения. Являются эффективными для поиска проблем, проявляющихся на редких входных шаблонах. Два примера:
* хрестоматийный — хэш-таблица с ограниченным количеством коллизий на один внутренний индекс (2 влезло, 3 — уже нет).
* комбинация данных привела к порождению NUL в транспорте, который формально двоичный, но конкретный кусок кода приёмника использовал неподходящее API (кажется, strlen).

Кроме того, в системах с внутренними временны́ми зависимостями ловят ситуации типа неправильной реакции на таймаут.

Другие, более специфичные для стресс-тестирований и тестирований на приёмку уровня военка/космос/etc., пропущу, потому что там ещё много можно говорить, но они вряд ли пригодятся хотя бы 1% читающих.

я возьму произвольную ф-ю любого из моих подчиненных, и с вероятностью в 50% смогу ее повалить «неожиданными» аргументами, при том, что их тесты отрабатывают без ошибок. Все их тесты пишутся для отчета, а не для реальных проверок.

Если у Вас нет возможности самому выбирать себе подчинённых — сочувствую.
Если такая возможность есть и Вы их получили не вчера — то почему до сих пор не привели в порядок?

Может, следует попросить в помощь классического армейского старшину, чтобы научил их любить Родину и начальство? А до того за каждую попытку теста «для галочки» — штрафовать? (Метод, конечно, экстремальный, но за намеренный обман — считаю, адекватен.)

И, наконец, зачем проблемы с вашими подчинёнными возводить в общий принцип?

Если я пишу функцию для деления двух чисел, то сначала продумаю ее интерфейс и возможные ошибки, дальше после написания кода, я вызываю ее вручную для проверки обработки всех вероятных критических моментов и валидности результата (например деление на ноль). JS позволяет провести все тесты прямо в консоли.

Да, это мощный аргумент против REPL и интерпретируемых языков. Уважил, запомню на будущее, хоть сам их использую в 99% своей практики:)

И ещё интересно, как Вы попытались вывернуть против меня мои примеры (это именно тут я приводил пример с умножением?) Только вот один момент есть. Умножение, деление — операции хоть и сложные в реализации, и имеющие хитрые подводные камни (типа INT_MIN/(-1)), но понятные всем, и воспроизвести тестовые примеры достаточно просто. (Кстати, не знаю, зачем Вам особое деление в JS.) А если что-то более хитрое вроде построения триангуляции для области? Или (ещё один мой любимый пример) паркинг и трансфер одновременно с двух сторон установленного звонка? Сама работа по придумыванию граничных случаев, которые требуют особых действий по реализации, может быть сравнимой по затратности с реализацией основного кода. Вы спокойно относитесь к тому, что выкидываете результат этой работы в мусор (а иначе нельзя это назвать, потому что уже через год всё забудется)? Если нет, то как документируете эти продуманные случаи, и почему это документирование не выглядит в виде тестов, которые можно в любой момент запустить и убедиться?

Считайте это юнит-тестами в ручном режиме.

Мне сложно считать «это» «юнит-тестами в ручном режиме» потому, что этих тестов нигде нет. Если бы я принимал Вашу работу, и код был бы чуть сложнее, чем очевидный, я бы сказал на это очень просто — «где доказательства? вы утверждаете, что всё проверили, а как в этом убедиться? может, вы тогда с девушкой поссорились, кошмар приснился, ещё что-то помешало?»

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

Спокойная же у Вас область, если возможно проходить сложные участки кода «пошагово в дебаг-режиме». Мне уже сложно вспомнить, когда такая лафа была в последний раз:) обычно только по «эскадрону моих логов шальных» можно выловить проблему, предварительно из дофига гигабайт итеративно отгрепав нужный кусок... (Этот абзац — не возражение по сути, но дополнительная иголочка в караван)

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

Аналогично.

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

Ой боюсь, сейчас придёт хор голосов, который скажет, что так проектировать вообще нельзя, и добавит какую-нибудь похабность. Но я спрошу иначе — а почему это, по-Вашему, превышение объёма тестов над объёмом модуля означает нереальность проведения синтетических тестов? Это всего лишь означает, что их будет больше, чем обычно. Но никто не требует писать их всех сразу (тут я, как могли заметить, резко расхожусь с TDD).

При этом уверен, что где-то написание файлов юнит-тестов полезно и даже необходимо.

Но не у вас, да? И при этом подчинённые всё равно их пишут и в них нагло мухлюют?