Вот еще один минус повальной любви к опенспейсам. В нормально обустроенной рабочей обстановке посторонние и соседи по кабинету не видят, ни твой материальный рабочий стол, ни твой экран…
Так одна девочка в ICQ проводила 85% своего рабочего времени.
А работа при этом вся была выполнена? Или всего 15%? Это ключевое, на мой взгляд.
P.S. А зачем держать людей, которые не понимают, что на работе вначале нужно сделать работу, а потом можно делать что угодно?
Значит проблема только в иррациональной плоскости — в глазах начальника.
Есть команда разработчиков, у нее есть цель, у нее полно работы, а Вася Пупкин посреди рабочего дня играет в контру.
Даже в этом случае нет ни малейшей проблемы в том, что Василий Пупкин играет в рабочее время в контру.
Проблема в том, что Васька не делает свою работу совсем, либо повышает риски не успеть к дедлайну (если вначале играет, а потом работает). И именно эту проблему нужно решать — определять ее причины и решать, возможно путем увольнения, если все совсем плохо…
Точно также с экономической точки зрения не понимаю выгоды использования FDR, вполне хватило бы 4x QDR на 40Гб
Не уверен, что по ценам они сильно отличаются. Кроме того, у FDR КПД выше, так как кодирование сменили — в 4x QDR скорость передачи данных была 32 гбит/с.
Атрибут ISMAP говорит, что по ссылке нужно еще передавать координаты клика, а серверное приложение по этим координатам сможет вывести какой-либо контент или перенаправить пользователя на другую страницу.
А он практически всегда изначально не оптимален. Так как заранее сложно угадать, где будут не очевидные проблемы с производительностью и на что нужно тратить время, а что подождет.
то дешевле будет купить дополнительное железо, а уж потом искать «бутылочные горлышки».
Покупка нового сервера — это несколько месяцев работы одного программиста по затратам + сервер будет к Вам ехать до двух месяцев. Всегда ли дешевле?
Тестирование вообще невозможно потому, что порядок вызова функций зависит от входных данных. Так?
При чем тут асинхронность вообще?
И от времени вызова, и от продолжительности работы функции. И от параллельности, если они еще могут параллельно выполняться.
Причем соверщенно пофиг какие именно эти 11 символов. Надо тестировать классы эквивалентности а не все варианты входных значений.
В асинхронном коде количество классов эквивалентности растет очень быстро. Произвольный порядок вызова нескольких функций — это еще простейший случай. Остальное будет зависеть от реализации этой асинхронности.
1. Вы не знаете контракт клиента полностью — это решается его исследованием
Я его не знаю, так как в реальной эксплуатации я его не контролирую. На той стороне может оказаться telnet, в который пишут /dev/urandom.
Я не вижу в чем проблема протестировать write_cb на неприятие мусора — вызвать его с мусором, и протестировать что результат совпадает с ожидаемым.
Это да, отдельно тестирование проблем не представляет.
2. Проблема взаимодействия асинхронного кода. Тут хотелось подробнее — в данном коде взаимодействие не показано вообще.
А это не суть важно. Как-то взаимодействуют и все. Сколько вариантов порядка вызова трех функций есть?
Дык TDD это про тестирование известных требований, а не про выдумывание новых.
Э, стоп. Те TDD это только проверка корректного поведения в случае корректных входных данных?
У меня требование — работать в случае получения от клиента любого мусора. Если получен мусор нужно ругнуться ошибкой и закрыть соединение.
Опять же я не могу предугадать, что будет делать клиент, а следовательно нормально покрыть тестами эту часть.
Корректное поведение предсказуемо и нормально покрывается тестами. Отлов некорректного поведения может быть только частичный, все некорректное поведение другой стороны — счетное множество комбинаций (пусть время квантуется).
Я бы насытил код ассертами на предусловия, постусловия и инварианты и прочей диагностикой, чтобы схватить ошибку как можно раньше.
Ну это же не тестирование, а инструменты постанализа, когда приложение уже упало от чего-то. Без них Fuzz_testing, можно сказать, невозможен.
А как точно и заранее определить, какой код оптимальный, а какой нет?
Вот есть у меня функция с O(n^5) — это плохо, а функция O(n log n) хорошо?
А если и ту и ту можно существенно оптимизировать (пусть первую до n^2, а вторую до n), подумав месяц?
А если первая выполняется 10мс один раз при старте системы, которая работает месяцами без перезапусков, а вторая выполняется при каждом обращении клиента и занимает половину времени обработки запроса?
Может быть, в таких условиях гораздо выгоднее будет контринтуитивное решение об оптимизации функции, которая и так имеет лучшую асимптотику?
Да, возможно, O(n^5) это технический долг, но придется ли его когда-нибудь отдавать? А эффективная на первый взгляд O(n log n) по факту отказывается долгом, хотя внешне не имеет к этому никаких предпосылок.
Из реальной практики, один раз при тестировании производительности некоторого приложения, я внезапно для себя протестировал производительность подсистемы записи логов этого приложения, при этом проблема оказалась даже не в скорости их записи на SSD, а в форматировании данных для записи. Без профайлера я бы не поверил, что такой простой на первый взгляд код может вызвать проблемы, но сработал эффект масштаба — функции записи в логи в максимальной детальности вызывались очень часто, таким образом совершенно неприметная на первый взгляд функция оказывалась в верхней строчке отчета профайлера.
В синхронном коде я тоже не вижу проблем.
В асинхронном коде я не вижу проблем протестировать каждый callback в отдельности, но вот как нормально тестировать их последовательности я не знаю.
Пусть есть такой запуск асинхронных операций:
io_service.async_read(socket, read_cb);
io_service.async_write(socket, write_cb);
io_service.async_timer(timeout, io_timeout_timer_cb);
которые внутри отрабатывают какой-либо протокол взаимодействия. Функции *_cb будут запущены при появлении запрошенного события, которые могут произойти в любом порядке.
Так как в общем случае клиент мне не подконтролен, то он может, как читать из сокета, так и писать в него, так и вообще отвалиться, допустив срабатывание таймера в любом порядке. Более того, клиент вообще может сгенерировать в сокет какой-либо мусор и write_cb должен это корректно обработать.
Я могу протестировать данный код в случае, если вторая сторона диалога исполняет свои обязанности корректно и вовремя или полностью или частично не исполняет(обрывы связи или длительные паузы после отправки или чтения какого-либо количества байт устроить всегда можно), но как тестировать другие случаи в комплексе я не знаю. Методики полноценного тестирования таких ситуаций мне неизвестны.
Я в таких случаях в основном использую нечто подобное Fuzz_testing эмулируя проблемы иногда хардварно (выключая порты на коммутаторе) или путем kill -9 клиентских или серверных компонент в произвольные моменты времени с последующим анализом детальных логов и coredump, если что-то пошло не так и они случились.
Если Вы меня просветите более эффективными методами, то я буду Вам очень благодарен, так как недавно я столкнулся с багом, который проявляется только в очень хитрой комбинации факторов и пришлось потратить немало времени, чтобы точно выяснить условия его возникновения. Правда, после того, как я понял из-за чего он возникает, решить проблему оказалось достаточно просто.
«метод может получить любую строку на вход, а тесты должны быть детерминированы по определению => метод не может быть протестирован вообще. „
Что-то Вы не в ту степь пошли.
Детерминизм тут будет в покрытии тестом всех ветвей функции и граничных условий. Для этого совершенно не обязательно перебирать все возможное множество входных параметров.
В то же время, как Вы будете полностью покрывать тестами код в смысле, который накладывает TDD, если, например, реальный порядок вызова функций у Вас может быть практически любой, при этом функции то друг от друга зависят, например это обработка одного TCP-соединения с клиентом?
PS. Про детерминированность тестов: en.wikipedia.org/wiki/Fuzz_testing
techblog.netflix.com/2012/07/chaos-monkey-released-into-wild.html
Да, такие методики существуют, но на мой взгляд они не укладываются в парадигму TDD.
Не обязательно у одной а/к. В пределах одного альянса стыковки тоже будут гарантированы. Я так летел вместо аэрофлотовского самолета на самолете какой-то другой а/к из-за того, что рейс первого сегмента задержали более чем на 8 часов по причине тумана в аэропорту вылета.
В любом случае для гарантированной стыковки билет должен быть один, а не просто два перелета подряд.
Нужно бороться и с недобросовестной выдачей по линии правоохранительных органов и с распространением сканов лишних документов по принципу это не Ваше дело.
При желании ни так сложно узнать, на чем я езжу и где я живу, но кричать на каждом углу об этом я не буду ибо зачем искушать лишних людей.
Честно говоря я не понимаю как типовой договор связан с социальной инженерией. Возможно дело в том, что мои единственные отношения с банком — дебетовый карточный счёт.
ключевое слово, например. Сам текст договора, конечно же не так интересен, как заполненные в нем поля.
Я сразу сказал — пусть гугл смотрит письма, если он делает это для выявления правонарушений, а не для сбора информации с целью шантажа и давления.
Гугл давно стал правоохранительным органом? Если еще не стал, то сбор информации вполне может считаться шантажем и давлением.
Какие беспочвенные обвиненя?
Вы сами сказали: «я не беспокоюсь что кто-то вдруг узнает что я маньяк, потому что я не маньяк.»
я думаю это сработает
Это срабатывает даже если у Вас нет сына, так как звонки давят на эмоции, а не на логику и эмоции проломить гораздо проще, чем логику.
У Вас написано дословно «можно отказаться только если на то есть веские основания», что принципиально неверно.
Единственное основание — волеизъявление родственников.
Если человек умер от неизвестной болезни, то это «представляет опасности для окружающих», те про это я тоже написал.
И сейчас у нас вскрытие — обычная процедура, от которой можно отказаться только если на то есть веские основания, а в некоторых случаях отказаться нельзя в принципе.
Отказаться от вскрытия можно в любом случае, если труп не криминальный и не представляет опасности для окружающих.
Основания — воля родственников, другие не нужны.
Другое дело, что ответственности за вскрытие при наличии отказа нет, а вскрытие очень хороший инструмент по заметанию следов врачебных ошибок.
Потому что если существуют потенциально опасные операции, которые можно сделать пользуясь только сканом паспорта — это проблема системы допускающей такие операции, выявятся такие проблемы — нужно будет с ними бороться.
Вначале это Ваши проблемы, когда приставы придут описывать Ваше имущество по долгу в пару миллионов, а когда Вы поседеете, и докажите, что брали в долг не Вы, то возможно измените свое мнение. Прецеденты ищутся на банки.ру.
Договора с банками, они ведь все типовые, что вы там хотите увидеть? Те же паспортные данные?
Социальная инженерия — знакомое понятие? Содержания договора хватит, чтобы сделать с счетами практически все что угодно.
Кто-то хочет использовать это в плохих целях? Ну так проблема именно в злом умысле, опять же, а не в доступности информации.
Какие плохие цели?! Вы же сами сказали, пусть смотрят. Только все решает грамотный пиар в правильной целевой аудитории. И если такие ролики увидят все Ваше ближайшее окружение, то психологический климат будет довольно сильно подпорчен.
Песня Слепакова «Люба — звезда Ютюба» хоть и в сатирической форме, но довольно хорошо описывает ситуацию.
Я бы хотел знать что мой сосед маньяк, если он маньяк и я не беспокоюсь что кто-то вдруг узнает что я маньяк, потому что я не маньяк.
Поищите прецеденты в интернете, чем могут закончится такие беспочвенные обвинения.
И моя мама никогда не поведется на ночной звонок «Ваш сын попал в милицию, везите взятку» потому что я не попадаю в милицию.
А этот ночной звонок к логике и знаниям отношения не имеет, а исключительно к психологической устойчивости человека. Именно по этому звонят ночью, чтобы еще больше дезориентировать жертву и отключить все остатки логики и знания. Именно по этому, на такие звонки иногда ведутся даже люди, у которых и сыновей то никогда не было.
Бояться открытости информации — это фобия потенциального преступника, который боится что кто-то про него узнает что-то едакое.
Ок. Разместите публично полные сканы Вашего паспорта, договоров с банками, банковских карт, конвертов с PIN-кодами, пароли, слепки ключей от всех замков, видео с камеры Вашего ноутбука, когда он в Вашей спальне и т.д…?
Список можно продолжать или сокращать, но в любом случае что-либо Вы не захотите открыть.
Нежелание публиковать некоторую информацию — это не страх, а разумный подход «это не Ваше дело». К очень многой информации доступ не публичен не по тому, что она компрометирующая, а просто по тому, что это не дело сторонних лиц.
Кроме того, если информация из категории «не ваше дело» попадет не в те руки, то это может нанести Вам достаточно серьезный ущерб, вплоть до летального исхода (это не шутка такая, если что, а реально случавшиеся преступления, раскрыть которые нередко чуть менее чем невозможно).
Для избранности достаточно или иметь зарплатную карту или получать зарплату на обычную карту.
Правда после кидалова с лимитами снятия денег в виде их снижения в 2-3 раза, без нормальных уведомлений, пользоваться картами этого банка как-то не хочется. Не дай бог окажешься где-то без возможности заплатить картой напрямую по любой причине и без возможности снять наличные и оплатить ими по причине сверхнизких лимитов. Собственно именно так я и узнал о внезапном изменении условий…
P.S. Если интересно, то основная моя расходная карта — платиновая виза от одного из коммерческих банков, правда за деньги.
На мой взгляд вопрос поставлен некорректно ибо бывают ситуации, когда железо «дешевле» программистов, а бывает и наоборот и нужно идти от затрат и потенциальных прибылей каждого из вариантов.
Пусть есть проект, в котором из-за плохого алгоритма производительность просела на 10% и нужен человекомесяц, чтобы заменить алгоритм на хороший.
Если система работает на одном сервере, то вполне может оказаться, что аренда чуть более дорогого сервера на год или более вперед обойдется в ту же сумму, что и месяц работы программиста. В этом случае увеличение мощности оборудования скорее выгодно, чем нет.
С другой стороны возьмем систему, где на своих площадках уже стоит 1000 серверов и 10% мощности — это еще 100шт. Вполне очевидно, что покупка и эксплуатационные расходы сотни серверов будут в разы больше месячной зарплаты программиста. Тут уже скорее выгодно оптимизировать, чем покупать железо.
А работа при этом вся была выполнена? Или всего 15%? Это ключевое, на мой взгляд.
P.S. А зачем держать людей, которые не понимают, что на работе вначале нужно сделать работу, а потом можно делать что угодно?
Даже в этом случае нет ни малейшей проблемы в том, что Василий Пупкин играет в рабочее время в контру.
Проблема в том, что Васька не делает свою работу совсем, либо повышает риски не успеть к дедлайну (если вначале играет, а потом работает). И именно эту проблему нужно решать — определять ее причины и решать, возможно путем увольнения, если все совсем плохо…
Не уверен, что по ценам они сильно отличаются. Кроме того, у FDR КПД выше, так как кодирование сменили — в 4x QDR скорость передачи данных была 32 гбит/с.
Там же почти весь контент это одна картинка:
Атрибут ISMAP говорит, что по ссылке нужно еще передавать координаты клика, а серверное приложение по этим координатам сможет вывести какой-либо контент или перенаправить пользователя на другую страницу.
А он практически всегда изначально не оптимален. Так как заранее сложно угадать, где будут не очевидные проблемы с производительностью и на что нужно тратить время, а что подождет.
Покупка нового сервера — это несколько месяцев работы одного программиста по затратам + сервер будет к Вам ехать до двух месяцев. Всегда ли дешевле?
И от времени вызова, и от продолжительности работы функции. И от параллельности, если они еще могут параллельно выполняться.
В асинхронном коде количество классов эквивалентности растет очень быстро. Произвольный порядок вызова нескольких функций — это еще простейший случай. Остальное будет зависеть от реализации этой асинхронности.
Я его не знаю, так как в реальной эксплуатации я его не контролирую. На той стороне может оказаться telnet, в который пишут /dev/urandom.
Это да, отдельно тестирование проблем не представляет.
А это не суть важно. Как-то взаимодействуют и все. Сколько вариантов порядка вызова трех функций есть?
Э, стоп. Те TDD это только проверка корректного поведения в случае корректных входных данных?
У меня требование — работать в случае получения от клиента любого мусора. Если получен мусор нужно ругнуться ошибкой и закрыть соединение.
Опять же я не могу предугадать, что будет делать клиент, а следовательно нормально покрыть тестами эту часть.
Корректное поведение предсказуемо и нормально покрывается тестами. Отлов некорректного поведения может быть только частичный, все некорректное поведение другой стороны — счетное множество комбинаций (пусть время квантуется).
Ну это же не тестирование, а инструменты постанализа, когда приложение уже упало от чего-то. Без них Fuzz_testing, можно сказать, невозможен.
Вот есть у меня функция с O(n^5) — это плохо, а функция O(n log n) хорошо?
А если и ту и ту можно существенно оптимизировать (пусть первую до n^2, а вторую до n), подумав месяц?
А если первая выполняется 10мс один раз при старте системы, которая работает месяцами без перезапусков, а вторая выполняется при каждом обращении клиента и занимает половину времени обработки запроса?
Может быть, в таких условиях гораздо выгоднее будет контринтуитивное решение об оптимизации функции, которая и так имеет лучшую асимптотику?
Да, возможно, O(n^5) это технический долг, но придется ли его когда-нибудь отдавать? А эффективная на первый взгляд O(n log n) по факту отказывается долгом, хотя внешне не имеет к этому никаких предпосылок.
Из реальной практики, один раз при тестировании производительности некоторого приложения, я внезапно для себя протестировал производительность подсистемы записи логов этого приложения, при этом проблема оказалась даже не в скорости их записи на SSD, а в форматировании данных для записи. Без профайлера я бы не поверил, что такой простой на первый взгляд код может вызвать проблемы, но сработал эффект масштаба — функции записи в логи в максимальной детальности вызывались очень часто, таким образом совершенно неприметная на первый взгляд функция оказывалась в верхней строчке отчета профайлера.
В асинхронном коде я не вижу проблем протестировать каждый callback в отдельности, но вот как нормально тестировать их последовательности я не знаю.
Пусть есть такой запуск асинхронных операций:
io_service.async_read(socket, read_cb);
io_service.async_write(socket, write_cb);
io_service.async_timer(timeout, io_timeout_timer_cb);
которые внутри отрабатывают какой-либо протокол взаимодействия. Функции *_cb будут запущены при появлении запрошенного события, которые могут произойти в любом порядке.
Так как в общем случае клиент мне не подконтролен, то он может, как читать из сокета, так и писать в него, так и вообще отвалиться, допустив срабатывание таймера в любом порядке. Более того, клиент вообще может сгенерировать в сокет какой-либо мусор и write_cb должен это корректно обработать.
Я могу протестировать данный код в случае, если вторая сторона диалога исполняет свои обязанности корректно и вовремя или полностью или частично не исполняет(обрывы связи или длительные паузы после отправки или чтения какого-либо количества байт устроить всегда можно), но как тестировать другие случаи в комплексе я не знаю. Методики полноценного тестирования таких ситуаций мне неизвестны.
Я в таких случаях в основном использую нечто подобное Fuzz_testing эмулируя проблемы иногда хардварно (выключая порты на коммутаторе) или путем kill -9 клиентских или серверных компонент в произвольные моменты времени с последующим анализом детальных логов и coredump, если что-то пошло не так и они случились.
Если Вы меня просветите более эффективными методами, то я буду Вам очень благодарен, так как недавно я столкнулся с багом, который проявляется только в очень хитрой комбинации факторов и пришлось потратить немало времени, чтобы точно выяснить условия его возникновения. Правда, после того, как я понял из-за чего он возникает, решить проблему оказалось достаточно просто.
Что-то Вы не в ту степь пошли.
Детерминизм тут будет в покрытии тестом всех ветвей функции и граничных условий. Для этого совершенно не обязательно перебирать все возможное множество входных параметров.
В то же время, как Вы будете полностью покрывать тестами код в смысле, который накладывает TDD, если, например, реальный порядок вызова функций у Вас может быть практически любой, при этом функции то друг от друга зависят, например это обработка одного TCP-соединения с клиентом?
Да, такие методики существуют, но на мой взгляд они не укладываются в парадигму TDD.
А тесты должны быть детерминированы по определению.
В любом случае для гарантированной стыковки билет должен быть один, а не просто два перелета подряд.
При желании ни так сложно узнать, на чем я езжу и где я живу, но кричать на каждом углу об этом я не буду ибо зачем искушать лишних людей.
ключевое слово, например. Сам текст договора, конечно же не так интересен, как заполненные в нем поля.
Гугл давно стал правоохранительным органом? Если еще не стал, то сбор информации вполне может считаться шантажем и давлением.
Вы сами сказали: «я не беспокоюсь что кто-то вдруг узнает что я маньяк, потому что я не маньяк.»
Это срабатывает даже если у Вас нет сына, так как звонки давят на эмоции, а не на логику и эмоции проломить гораздо проще, чем логику.
Единственное основание — волеизъявление родственников.
Если человек умер от неизвестной болезни, то это «представляет опасности для окружающих», те про это я тоже написал.
Отказаться от вскрытия можно в любом случае, если труп не криминальный и не представляет опасности для окружающих.
Основания — воля родственников, другие не нужны.
Другое дело, что ответственности за вскрытие при наличии отказа нет, а вскрытие очень хороший инструмент по заметанию следов врачебных ошибок.
Вначале это Ваши проблемы, когда приставы придут описывать Ваше имущество по долгу в пару миллионов, а когда Вы поседеете, и докажите, что брали в долг не Вы, то возможно измените свое мнение. Прецеденты ищутся на банки.ру.
Социальная инженерия — знакомое понятие? Содержания договора хватит, чтобы сделать с счетами практически все что угодно.
Какие плохие цели?! Вы же сами сказали, пусть смотрят. Только все решает грамотный пиар в правильной целевой аудитории. И если такие ролики увидят все Ваше ближайшее окружение, то психологический климат будет довольно сильно подпорчен.
Песня Слепакова «Люба — звезда Ютюба» хоть и в сатирической форме, но довольно хорошо описывает ситуацию.
Поищите прецеденты в интернете, чем могут закончится такие беспочвенные обвинения.
А этот ночной звонок к логике и знаниям отношения не имеет, а исключительно к психологической устойчивости человека. Именно по этому звонят ночью, чтобы еще больше дезориентировать жертву и отключить все остатки логики и знания. Именно по этому, на такие звонки иногда ведутся даже люди, у которых и сыновей то никогда не было.
Ок. Разместите публично полные сканы Вашего паспорта, договоров с банками, банковских карт, конвертов с PIN-кодами, пароли, слепки ключей от всех замков, видео с камеры Вашего ноутбука, когда он в Вашей спальне и т.д…?
Список можно продолжать или сокращать, но в любом случае что-либо Вы не захотите открыть.
Нежелание публиковать некоторую информацию — это не страх, а разумный подход «это не Ваше дело». К очень многой информации доступ не публичен не по тому, что она компрометирующая, а просто по тому, что это не дело сторонних лиц.
Кроме того, если информация из категории «не ваше дело» попадет не в те руки, то это может нанести Вам достаточно серьезный ущерб, вплоть до летального исхода (это не шутка такая, если что, а реально случавшиеся преступления, раскрыть которые нередко чуть менее чем невозможно).
Правда после кидалова с лимитами снятия денег в виде их снижения в 2-3 раза, без нормальных уведомлений, пользоваться картами этого банка как-то не хочется. Не дай бог окажешься где-то без возможности заплатить картой напрямую по любой причине и без возможности снять наличные и оплатить ими по причине сверхнизких лимитов. Собственно именно так я и узнал о внезапном изменении условий…
P.S. Если интересно, то основная моя расходная карта — платиновая виза от одного из коммерческих банков, правда за деньги.
Пусть есть проект, в котором из-за плохого алгоритма производительность просела на 10% и нужен человекомесяц, чтобы заменить алгоритм на хороший.
Если система работает на одном сервере, то вполне может оказаться, что аренда чуть более дорогого сервера на год или более вперед обойдется в ту же сумму, что и месяц работы программиста. В этом случае увеличение мощности оборудования скорее выгодно, чем нет.
С другой стороны возьмем систему, где на своих площадках уже стоит 1000 серверов и 10% мощности — это еще 100шт. Вполне очевидно, что покупка и эксплуатационные расходы сотни серверов будут в разы больше месячной зарплаты программиста. Тут уже скорее выгодно оптимизировать, чем покупать железо.