К сожалению «дебилов, которые бросают себе на счёт по 100 рублей» очень много и мы их немного «переучили — теперь они бросают по 500.
Ну меню пуск вы открываете за день >100 раз, а оплату производите даже не каждый день — задержка в ней — не так страшно. А само тестирование — это да, согласен, издевательство.
а что если так. сервер падает (топор в него воткнули). ip переключается на другую машину. GW узнает о смене мака привязанного к ip только, когда протухнет его arp таблица. т.е пока arp на шлюзе старый — пакеты будут лететь в лежащую машину. ARP может и 30 секунд протухать. 30 секунд даунтайма?
Дело в том, что есть довольно много людей считающих что «компилятор тупой». А еще хуже, что есть люди, которые так считают и проведут «псевдо бенчмарк». Благодаря плаванию частоты, энергосбережению проца и просто кривым рукам эти люди получат что for быстрее while или наоборот. Сделают вывод и будут это доказывать окружающим.
В этой статье я не делаю открытие для себя или для тех, кому это и «так понятно». Я пытаюсь натолкнуть людей на то, что иногда нужно заглянуть внутрь и внутри совсем не страшно.
UPD. И я думаю есть те, кто спорит про while(1) и while(1==1)
А Вы редактируете потому что генерит, что то не соответствующее базе или Вы посто в базе не все покрываете условиями?
Ну это кроме условий подпадания строки под валидаторы email, phone — тут понятно.
Спасибо за статью!
Давно хочу начать использовать кодогенерацию, кто что может сказать по этому поводу? Может неочевидные плюсы (помимо «быстро») и минусы такого подхода в реальных проектах. Или кто видел неожиданности с gii?
В Ruby-on-Rails (2.3.3), которым я когда то пользовался была кодогенерация, которая отбила желание её использовать на долгие годы вперед — не произойдет ли так же с gii?
Знать об ошибке, залогировать её и доложить в мониторинг — это одно. об ошибке bad request стоит докладывать — но это не повод нарушать http и на кривой запрос отвечать не 400, а 500 — как будто это внутреняя ошибка сервера. Тем более это не повод, чтобы код падал.
Мне ничего не мешает мониторить http status 400
Ну например — разработчик может в своем коде воспользоватся модулем php, которого еще нет в скриптах разворачивания.
Значит нужно либо добавить модуль в скрипты, либо изменить код.
Это один из множества примеров
Поверьте, любой прект можно развернуть руками, любую работу автоматизировать. Любую медленную операцию — оптимизировать или кешировать.
так что я не вижу особой проблемы в том, что Вы говорите.
Этим мы по сути проверяем схему развертывания новой ноды в нашем кластере. По сути это тестирование автоматизации горизонтального масштабирования — у нас оно выполняется нажатие кнопки в панели полностью автоматически. Проверить правила автоматического развертывания сервисов для puppet, проверить, что конфиги в хранилище актуальны, и многое другое — это спасение от неожиданностей на проде. Неожиданностей вида — «а вот на эту новую ноду надо доустановить такой-то модуль php».
Проект и сейчас сильно завязан на системные решения, системное администрирование у нас сложное и по этому полностью автоматизировано — его тоже следует проверять. Развертка с нуля у нас — это установка 5и виртуалок и их настройка — минимальный размер кластера для нашего продукта.
Невозможен? А как может оказаться так, что продукт нельзя установить на новую машину?
30 минут:
* 2 схемы деплоя: итеративная миграция и с нуля (с установкой debian, конфигурированием и разверкой кода) — на это нужно 5 минут.
* selenium у нас обходит 100% интерфейса — на это нужно 15 минут.
* 1-5 минут нужно на имеющиеся unit и функциональные selenium тесты старых багов. Да, к сожалению selenium штука не быстрая
* 1-5 минут нужно на тесты библиотек.
Вот и 22-30 минут на билд. Билдим мы 3 бранча — master (stable), alpha (alpha-версия), beta (beta-версия).
Честно — не знаю, но мне тоже это интересно.
Так и есть. Пока выполняется ajax-запрос (который тормозит) у пользователя «крутится анимация».
Ну меню пуск вы открываете за день >100 раз, а оплату производите даже не каждый день — задержка в ней — не так страшно. А само тестирование — это да, согласен, издевательство.
В этой статье я не делаю открытие для себя или для тех, кому это и «так понятно». Я пытаюсь натолкнуть людей на то, что иногда нужно заглянуть внутрь и внутри совсем не страшно.
UPD. И я думаю есть те, кто спорит про while(1) и while(1==1)
Ну это кроме условий подпадания строки под валидаторы email, phone — тут понятно.
Давно хочу начать использовать кодогенерацию, кто что может сказать по этому поводу? Может неочевидные плюсы (помимо «быстро») и минусы такого подхода в реальных проектах. Или кто видел неожиданности с gii?
В Ruby-on-Rails (2.3.3), которым я когда то пользовался была кодогенерация, которая отбила желание её использовать на долгие годы вперед — не произойдет ли так же с gii?
Мне ничего не мешает мониторить http status 400
Значит нужно либо добавить модуль в скрипты, либо изменить код.
Это один из множества примеров
так что я не вижу особой проблемы в том, что Вы говорите.
Проект и сейчас сильно завязан на системные решения, системное администрирование у нас сложное и по этому полностью автоматизировано — его тоже следует проверять. Развертка с нуля у нас — это установка 5и виртуалок и их настройка — минимальный размер кластера для нашего продукта.
Невозможен? А как может оказаться так, что продукт нельзя установить на новую машину?
30 минут:
* 2 схемы деплоя: итеративная миграция и с нуля (с установкой debian, конфигурированием и разверкой кода) — на это нужно 5 минут.
* selenium у нас обходит 100% интерфейса — на это нужно 15 минут.
* 1-5 минут нужно на имеющиеся unit и функциональные selenium тесты старых багов. Да, к сожалению selenium штука не быстрая
* 1-5 минут нужно на тесты библиотек.
Вот и 22-30 минут на билд. Билдим мы 3 бранча — master (stable), alpha (alpha-версия), beta (beta-версия).