Перенести на другой день, попросить оставить на месте выдачи — всё можно, проделывал. Единственный минус — с точным временем доставки договориться сложно — у них график и логистика всякая вредная =)
Тут есть нюанс про самовывоз — если курьер позвонил до отгрузки, можно попросить оставить на месте выдачи и самому забрать в тот же день. А вот если оформлять самовывоз через телефон-оператор-единая-справочная-в-Москве, то только на сделующий день и Москвичи понятия не имеют даже что пол года назад их Новосибирское отделение переехало и размещается по другому адресу XD
К примеру Новосибирск, ЕМС на Гагаринской, 3 из 4х посылок — около 9ти утра прозвон: «в течение часа по адресу доставки будете?». Один раз да, без звонков прилепили стикер о неудачной доставке на дверь подъезда и всё.
Json-схема создается после/до написания функционала, она сама по себе — функциональный тест.
По ней как раз происходит валидация данных и по ней же строится документация (Объект такой-то содержит поля такие-то и включает объекты такие-то)
Эдакая круговая порука:
— Если после изменений кода валится валидация — проверь свой код.
— Если изменил формат выдачи — поменяй схему, а то валидацию не пройдет и дока устареет.
Просто посмотрите в сторону NetBeans или phpStorm. В последнем помимо стандартного парсера кода, показывающего простейшие детские косяки есть возможность прикрутить phpMess Detector и CodeSniffer.
Понятно, но бесполезно.
Я намекал на то что эту строку и еще пару аналогичных можно выкинуть, т.к. они не несут никакой практической пользы. При входе в цикл $lc_i в любом случае инициализируется значением ord($this->gif[$this->pnt + $sum]), где $sum = 2.
Я таки поясню =)
Обычно при возникновении ошибки функция должна вернуть false/NULL/кинуть исключение, чтобы на уровне выше можно было адекватно отреагировать на неё. В вашем случае отдается 0, что можно понять и… в stdout срется текст, что не есть гуд.
Почему? Если ваш скрипт будет использован на фронтенде, а не как консольная приблуда — чтобы гарантировать нормальный вывод данных пользователю необходимо использовать ob_start чтобы заглушить вывод сообщения.
Так с отсутствия «хорошего стиля программирования» и начинаются:
— Ну а че? Пусть себе лежат нигде не используемые приватные функции, тебе что мешают?
— Зачем включать параноидальные E_NOTICE, подумаешь, необъявленная параменная проскочит.
— Ну и что, что WARNING'и сыпятся, код-то работает!
— Что-то error.log файлы распухают, давай их выключим, кто в них смотрит?
Да я ж не против :)
Если имеется ввиду что этот инстанс-бранч будет использоваться и программистом и тестировщиком одновременно, тогда вопрос опять же снимается =) При моем подходе любой из них может поменять ветку и поломать работу другого. Но если тестирование и разработка ведется на разных инстансах — подход вполне себе жизнеспособен, каждый знает в какой ветке сидит и что делает.
И да, про автодеплой было бы весьма интересно почитать.
А зачем нужна тестовая площадка под каждую ветку? Если у вас 100% покрытие функциональными тестами — вопрос снимается =)
Если присутствует ручное тестирование, то ничего не мешает иметь 1-2 настроеных инстанса приложения/виртуалки и переключаться между ветками обыкновенным git checkout.
У нас при активных 22 ветках с фичами с этим делом вполне справляется 2 тестовых инстанса autotest.some.local для jenkins'а и тестировщик.some.local для ручного тестирования.
Причем переключение на ветку и перенастройка окружения под неё делается двумя консольными командами:
git co feature/**** && phing config (да, настройки приложения для боя/тестирования/разработки разруливаются phing'ом)
Не шар, но экспериментально доказано: если положить телефон на глянцевую поверхность крышки ноутбука acer aspire 5920G, в любое место, даже ровно посередине — рано или поздно телефон уползет
Аналогичная ситуация. По трекингу посылка лежит на почте готовая к тому чтобы её забрать. Извещения носит другое отделение «спустя месяц или вообще никогда», так что смотришь трекинг, идешь на почту, книга учета, бланк, заполняешь, получаешь посылку)
www.g0l.ru/blog/n3793
www.g0l.ru/blog/n3799
www.g0l.ru/blog/n3792
Тут есть нюанс про самовывоз — если курьер позвонил до отгрузки, можно попросить оставить на месте выдачи и самому забрать в тот же день. А вот если оформлять самовывоз через телефон-оператор-единая-справочная-в-Москве, то только на сделующий день и Москвичи понятия не имеют даже что пол года назад их Новосибирское отделение переехало и размещается по другому адресу XD
Или для объектов:
В последнем примере либо поле существует и null, либо в нем лежит какая-то структура, которая будет валидироваться согласно properties
По ней как раз происходит валидация данных и по ней же строится документация (Объект такой-то содержит поля такие-то и включает объекты такие-то)
Эдакая круговая порука:
— Если после изменений кода валится валидация — проверь свой код.
— Если изменил формат выдачи — поменяй схему, а то валидацию не пройдет и дока устареет.
Я намекал на то что эту строку и еще пару аналогичных можно выкинуть, т.к. они не несут никакой практической пользы. При входе в цикл $lc_i в любом случае инициализируется значением ord($this->gif[$this->pnt + $sum]), где $sum = 2.
$lc_i = ord($this->gif[$this->pnt + 2]);Раз уж вы ратуете за экономию тактов процессора?
Обычно при возникновении ошибки функция должна вернуть false/NULL/кинуть исключение, чтобы на уровне выше можно было адекватно отреагировать на неё. В вашем случае отдается 0, что можно понять и… в stdout срется текст, что не есть гуд.
Почему? Если ваш скрипт будет использован на фронтенде, а не как консольная приблуда — чтобы гарантировать нормальный вывод данных пользователю необходимо использовать ob_start чтобы заглушить вывод сообщения.
Позиция автора ясна — сделать так чтобы работало быстро.
Если это причесать, убрать странности типа:
Получится вполне ничего ;)
— Ну а че? Пусть себе лежат нигде не используемые приватные функции, тебе что мешают?
— Зачем включать параноидальные E_NOTICE, подумаешь, необъявленная параменная проскочит.
— Ну и что, что WARNING'и сыпятся, код-то работает!
— Что-то error.log файлы распухают, давай их выключим, кто в них смотрит?
Если имеется ввиду что этот инстанс-бранч будет использоваться и программистом и тестировщиком одновременно, тогда вопрос опять же снимается =) При моем подходе любой из них может поменять ветку и поломать работу другого. Но если тестирование и разработка ведется на разных инстансах — подход вполне себе жизнеспособен, каждый знает в какой ветке сидит и что делает.
И да, про автодеплой было бы весьма интересно почитать.
Если присутствует ручное тестирование, то ничего не мешает иметь 1-2 настроеных инстанса приложения/виртуалки и переключаться между ветками обыкновенным git checkout.
У нас при активных 22 ветках с фичами с этим делом вполне справляется 2 тестовых инстанса autotest.some.local для jenkins'а и тестировщик.some.local для ручного тестирования.
Причем переключение на ветку и перенастройка окружения под неё делается двумя консольными командами:
git co feature/**** && phing config (да, настройки приложения для боя/тестирования/разработки разруливаются phing'ом)