ITnan

Все публикации Хабрахабр и Гиктаймс в одном месте
Выбран стиль: blue


  1. VolCh
    /#22106894

    Перед тем как гуглить на 99% был уверен, что ризен и 15 дюймов. ASUS TUF Gaming F17 я имел в виду примерно, желательно в максимальной комплектации ))

  2. VolCh
    /#22106596

    Из модемных историй: у ГТС был свой модемный пул с тарифом в кредит (в счёт за межгород включалось). Рейт был выше предоплаченных, менялся по времени суток, самый дешёвый ночью, но в принципе приемлемо, кроме, кажется, двух часов утром, с 6 до 8 или с 7 до 9. Там был отсекающий — на порядок дороже. А до него самый дешёвый. Ну и часто серфишь ночью и вырубаешься, а комп что-то качает, качалка почему-то через раз дисконнектила по расписанию, или автодозвон срабатывал. Просыпаешься и… ля. А потом настоящий кредит брал чтоб расплатиться.

  3. VolCh
    /#22106514

    Вот сейчас пытался сначала вспомнить, а потом нагуглить — были какие-то совсем небольшие разъёмы, из реальных плат под них только модемы видел. Не VLB :)

  4. VolCh
    /#22106488

    98 Second Edition была, в 95 было что-то непонятное OSR2 )

  5. VolCh
    /#22106104

    Даже для самой простой функции вам не хватит одного теста. Ведь надо рассмотреть позитивные и негативные сценарии, граничные условия, классы эквивалентности.

    Неверное понимание TDD. Оно (она?) не про то, чтобы покрыть код тестами для всех сценариев,. Нет ни цели такой, ни свойства у него. Оно про то, что прежде чем менять, логику кода, нужно написать тест, который падает на отсутствующем или старом коде Покрытие некоторых сценариев в итоге — бесплатный бонус.


    Вот видишь, что, например, деление на ноль может быть в имеющиеся коде и хочешь особую обработку слелать — пишешь тест по TDD, смотришь, что этой обработки нет (тест красный) и делаешь. А если знаешь, что исключение будет и пишешь тест на то, что оно броситься — это уже выход за рамки TDD, это уже и не разработка вовсе, а просто тестирование уже написанного кода. В TDD пишешь новый или меняешь существующий тест, когда собираешься писать новую или менять существующую логику. Если пишешь тест, который должен проходить без изменений кода, то ты уже не разработкой занимаешься, а тестированием, фиксацией поведения. А если собираешься писать код для реализации какого-то требования и пишешь тест, который должен упасть, но не падает, то надо разбираться — требование уже реализовано кем-то когда-то или тест плохой, ничего не тестирует или тестирует что-то другое.

  6. VolCh
    /#22106078

    Бывает, что думаешь, что знаешь цвет теста, а на самом деле ошибаешься. Пишешь new User, перед тем как создать класс User а оказывается где-то в зависимости он уже есть и умная IDE его и портировал незаметно.

  7. VolCh
    /#22106070

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

  8. VolCh
    /#22105472

    Да, к 98 ближе всего w2k по UI, емнип

  9. VolCh
    /#22105414

    Стремления понять можно легко, методы сложно.

  10. VolCh
    /#22105386 / +2

    Я ж сказал, если не соответствует действительности. А если соответствует, то или молчать, или "да, это так, но мы работаем над этим. Спасибо, что показали, что для наших пользователей э о важнее, чем мы думали — мы поменяем приоритеты". Ну и результаты аудитов с комментариями "мы не идеальны, но с благами и секьюрити ситуация на приемлемо, удовлетворительно уровне"