Описание проблемы будто с меня писалось… надеюсь опыт «выхода из кризиса», описанный во второй части поможет решить проблему. Спасибо, что дали мне это понять!
Миссия компании – быть «самой заботящаяся о клиенте компанией на Земле». Будь то возврат покупки или сломанный девайс – Амазон всегда стремится оставить клиента довольным, даже ценой собственных убытков, свято веря, что доверие клиента – самый дорогой актив.
После общения с саппортом по вопросам сервиса Amazon SES никак не могу согласиться с этим утверждением. Ребята имеют кучу шаблонов которыми отвечают бездумно, решения принимаются рандомно (в одной и той же ситуации) — видимо все зависит от настроений конкретного сотрудника:)
Solo Piano (sky.fm) — даже не знаю… можно сказать, что от части классика, но далеко не всегда.
«музыка без слов имеет самое большое позитивное влияние» — вот это для меня полностью правда!
Пробовал рок/электро (то, что уже слушал не раз или новое) — не то, что не помогало, а даже иногда отвлекало.
Ответил «Строго придерживаюсь ООП» — но это верно процентов этак на 80.
«Реализую MVC», «Комбинирую технологии» и «выбираю конкретный фреймворк» расползлись по оставшемся 20.
А вообще DeusModus прав на счет ЧБ
Чтобы понять что свойство защищенное (при выборе protected $var вместо protected $_var) необходимо будет идти к месту его объявления (это если без IDE).
А в IDE приёдется сделать дополнительные телодвижения, чтобы посмотреть аннотацию (Ctrl+B и т.п.). Для чтения, имхо, лучше $this->_var, так сразу видно.
Люди, как мне видится, так вот просто не расстанутся с анонимностью… в любых цивилизациях всегда (изначально) присутствует тайна, и изменить этот принцип врядли представляется возможным. Тем более за 10-20 лет… возраст то у этого явления порядка на 2 больше.
Клиент: «Почему до сих пор нет сообщения в zenddesk о времени начала и продолжительности неработоспособности серверов (не только наших проектов, а вообще всех)?» Контора: «Оповещение о недоступности серверов в облаке не было добавлено в публичный поток новостей, поскольку неполадки коснулись лишь небольшой части наших клиентов, в том числе, к сожалению, Вашего.»
Хорошо, конечно… но почему бы не оповещать эту «небольшую часть клиентов» в индивидуальном порядке, раз их число настолько ничтожно, что не стоит из-за этого «украшать» публичный поток?
Что-то здесь не то… на дзендеске до сих пор ничего не появилось, или я не там смотрю?
Вам, Azy, ещё повезло… у нас так вообще один (из тех, что на оверсане) проект, судя по нагиосу, не откликался до 22:00.
Отдельные деньги, которые платятся за поддержку, а не за хостинг, тоже как-то на процесс «информирования клиентов» не повлияли. Плохо, товарищи… очень плохо! Оценка — неудовлетворительно!
Ответ хостера по данной проблеме: Вчера у нас был сбой в облаке — несколько хостов виртуализации перешли в неработоспособное состояние и система мониторинга не оповестила администраторов (по ошибке, вообще такое оповещение всегда срабатывает). Поиск решения проблемы несколько затянулся, вдобавок к тому, что сама проблема была обнаружена не сразу. Сейчас необходимые новые уведомления в системе мониторинга добавлены и неприятностей такого характера больше не будет. (лир.отст. — это мы ещё посмотрим) Процесс «поднятия» серверов с неработоспособных хостов виртуализации происходил в порядке, в котором они были расположены в БД Zen. Таким образом задержка ***.ru в какой-то степени связана с этим. Плюс к этому, сервер некоторое время находился в swap-е, в то время как сотрудники были уверены, что он еще не «поднялся» с неработоспособного хоста виртуализации на другом (новом) хосте. Надеемся, что такие недоразумения впредь происходить не будут.
В документации, кстати, много уже предложено решений на эту тему (с использование debug_backtrace), датированных 2009 г. Есть даже, на мой беглый взгляд, более элегантные. Единственное чего не учитывают — call_user_func, зато с разбором файла справились лучше.
Ответил бы с пояснением (массивами), но не хочу писать некрасивый коммент (без разметки), кармы не хватает.
Вы сделайте var_dump($_FILES) имея форму с полями файлов, имена которых — files[pictures][animals][], files[pictures][animals][]. Как посмотрите их структуру, ещё раз подумайте над использованием for.
Кстати, имена могут быть именноваными (files[pictures][animals][dog] например)… тогда for точно не подойдет.
Всех очень устраивает for… очень удобный и быстрый цикл. Но что-то я не вижу «навскидку» решения поставленной задачи с помощью этого цикла, да так, чтобы «красиво» было.
Не дадите нам всем посмотреть на Ваш вариант?
Но учтите, что в данной задаче есть не только массивы вида files[], но и любого измерения (многомерные, типа files[level1][level2][level3] и т.д). Спасибо.
Напомню: не обязательно перегружать сам глобальный массив, можно в необходимом месте получать его представление и именно там добавить /* записку_охотника */
После общения с саппортом по вопросам сервиса Amazon SES никак не могу согласиться с этим утверждением. Ребята имеют кучу шаблонов которыми отвечают бездумно, решения принимаются рандомно (в одной и той же ситуации) — видимо все зависит от настроений конкретного сотрудника:)
«музыка без слов имеет самое большое позитивное влияние» — вот это для меня полностью правда!
Пробовал рок/электро (то, что уже слушал не раз или новое) — не то, что не помогало, а даже иногда отвлекало.
«Реализую MVC», «Комбинирую технологии» и «выбираю конкретный фреймворк» расползлись по оставшемся 20.
А вообще DeusModus прав на счет ЧБ
А в IDE приёдется сделать дополнительные телодвижения, чтобы посмотреть аннотацию (Ctrl+B и т.п.). Для чтения, имхо, лучше $this->_var, так сразу видно.
php.net в копилку протеста…
Контора: «Оповещение о недоступности серверов в облаке не было добавлено в публичный поток новостей, поскольку неполадки коснулись лишь небольшой части наших клиентов, в том числе, к сожалению, Вашего.»
Хорошо, конечно… но почему бы не оповещать эту «небольшую часть клиентов» в индивидуальном порядке, раз их число настолько ничтожно, что не стоит из-за этого «украшать» публичный поток?
Вам, Azy, ещё повезло… у нас так вообще один (из тех, что на оверсане) проект, судя по нагиосу, не откликался до 22:00.
Отдельные деньги, которые платятся за поддержку, а не за хостинг, тоже как-то на процесс «информирования клиентов» не повлияли. Плохо, товарищи… очень плохо! Оценка — неудовлетворительно!
Ответ хостера по данной проблеме:
Вчера у нас был сбой в облаке — несколько хостов виртуализации перешли в неработоспособное состояние и система мониторинга не оповестила администраторов (по ошибке, вообще такое оповещение всегда срабатывает). Поиск решения проблемы несколько затянулся, вдобавок к тому, что сама проблема была обнаружена не сразу. Сейчас необходимые новые уведомления в системе мониторинга добавлены и неприятностей такого характера больше не будет. (лир.отст. — это мы ещё посмотрим)
Процесс «поднятия» серверов с неработоспособных хостов виртуализации происходил в порядке, в котором они были расположены в БД Zen. Таким образом задержка ***.ru в какой-то степени связана с этим. Плюс к этому, сервер некоторое время находился в swap-е, в то время как сотрудники были уверены, что он еще не «поднялся» с неработоспособного хоста виртуализации на другом (новом) хосте. Надеемся, что такие недоразумения впредь происходить не будут.
Вы сделайте var_dump($_FILES) имея форму с полями файлов, имена которых — files[pictures][animals][], files[pictures][animals][]. Как посмотрите их структуру, ещё раз подумайте над использованием for.
Кстати, имена могут быть именноваными (files[pictures][animals][dog] например)… тогда for точно не подойдет.
Не дадите нам всем посмотреть на Ваш вариант?
Но учтите, что в данной задаче есть не только массивы вида files[], но и любого измерения (многомерные, типа files[level1][level2][level3] и т.д). Спасибо.
Напомню: не обязательно перегружать сам глобальный массив, можно в необходимом месте получать его представление и именно там добавить /* записку_охотника */