Что-то мне не кажется хорошей идеей использование $object::$static_public_property вместо foo::$static_public_property.
Как бы обращение к объекту подразумевает под собой динамику (объект — это динамическая сущность класса). Обращение к классу подразумевает статику («не меняется для каждого объекта»). Обращаясь за статическими свойствами к объекту вы вводите в заблуждение читателя. Я понимаю, что разница все равно есть (:: vs ->), но она становится менее заметной.
Есть один use case, когда такое может пригодиться. Когда мы не знаем, какого класса у нас объект, но хотим взять у него константу или статику. Но что-то мне кажется, что это больше «пахнет» ошибкой проектирования, чем реальной необходимостью…
Проблема поднята актуальная. Но тема не раскрыта. Во-первых, все описано сумбурно и поверхностно. Во-вторых, таблицы и планы работают только в вакууме. В реальной жизни все намного сложнее и динамичнее, и методики должны быть гибкими. Основная сложность не в том, чтобы составить план на день (таблицей или как угодно), а в том, чтобы его соблюсти.
Практика показывает, что даже такой сервис («который невозможно использовать как настоящую ФС») востребован. Бэкапы, архивы, помойки и обменники. Есть множество сервисов (как публичных, так и внутрекорпоративных, например), с которыми было бы удобно использовать «резиновое» хранилище. А тот факт, что файл можно отдать в веб по адресу my-s3-storage.mysite.ru/filename (как у S3) придает хранилищу еще больший функционал.
Причем в данном случае, при внезапной нехватке места вы просто отдадите ошибку. И это ничего не поломает, так как пользователь обязан обрабатывать такие ошибки. В смысле, у пользователя ничего не упадет, в отличии от ситуации, которую вы описывали выше.
Вывод: такой сервис — хороший компромисс между резиновостью и качеством. А резиновые диски для виртуалок, на мой взгляд не нужны. Проблемы с большими перепадами требуемого места на диске нужно решать иначе…
Ага, такого сервиса не хватает. Для бэкапов, например. Вообще, мне очень нравится организация Amazon S3. И вебморда есть, и API, и права доступа, и отдача по HTTP, что очень важно, под своим доменом. Я держу у вас машину, но файлохранилище (в том числе файлопомойку) держу отдельно на амазоне.
Непонятные ощущения после прочтения. С одный стороны тема облачноо хостинга (в частности) сейчас в Беларуси довольно остра, т.к. такие услуги предлагает на рынке только одна компани, а их качество пока оставляет желаь лучшего. С другой, не понятно, чего ждать от мероприятия. Это будет тусовка разработчиков или пользователей облаков? Кто будет экспертами? Кто будет читать доклады? Боюсь, что в итоге все посто из почетного утренника ни о чем перейдет в пьянку.
А можно подробнее, как у вас так мало получается? Это S3? Я считал, что 100 Гб бэкапов получалось около 12 баксов в мес. Ну пусть надо не 100, 1 Гб — 1,2 бакса. У вас бэкапов меньше гига?
Я в последнее время убедился в том, что всегда надо быть на готове. Стремительное развитие технологий и конкуренция на рынке в итоге привели к понижению качества услуг и их стоимости. Если раньше дорогой физический сервер или VPS работали практически безотказно, то сейчас в дешевых облаках постоянные проблемы по всем фронтам. Надо просто быть на готове — постоянные бекапы и одно из двух: или резервный сервер всегда под рукой, или быстрая автоматизированная развертка из бэкапов.
Консоль — это, конечно, хорошо. Но в нормальной ситуации она вообще не должна никогда понадобится… А если уж и понадобится, так 15 минут можно и тормоза потерпеть. Не совсем понятно, зачем на нее тратится столько усилий. Ради маркетинга, что ли?
Мне вот больше интересно было бы получить возможность выбора системы тарификации — шейпер и без оплаты за дисковые I/O или быстро, но с оплатой. Когда у меня возникли проблемы в некотором месте и деньги потекли рекой, было большое желание по-быстрому перейти на [не буду говорить кого, а то сочтете за рекламу]. Мне с моими проектами лучше бы медленный сервис и время на реакцию, чем скорость и дикие счета.
Вообще, я являюсь клиентов двух облачных компаний — Селектела и [не буду говорить кого, а то сочтете за рекламу]. Плюсы и минусы есть у всех. Поддержка мне больше нравится в Селектеле, панель у [...], тарифы в Селектеле ниже (если не учитывать косяки с I/O, из-за которых деньги улетают моментально… Падений давно не было ни у тех, ни у других.
Наверное было бы лучше написать в заголовке «на одной частоте», а не «в одном диапазоне»? Диапазон частот может быть широким и каналы можно формировать на разных несущих частотах диапазона. А тут фишка именно в том, что несущая одна.
Абсолютно верно. Тут даже спорить не о чем. Я и сам по молодости часто забывал проtrimить строки, в результате чего иногда всплывали подобные косяки. Ну и что, себя и винил в данной ситуации. А пользователь имеет полное право всегда вставлять с пробелами по краям, кроме пароля (или другого скрытого поля).
А мне все больше нравится рисовалка в Google Docs. Просто и удобно. В то же время текстовый редактор гугла больше раздражает, чем оказывается полезным.
Да, в первую очередь локальные переменные появятся в циклах. А вообще, в шаблоне могут быть вычисления (которые связаны с логикой представления), и их результатам самое место в локальных переменных.
Что касается избегания, то это как минимум ничем не обосновано. Локальные переменные нужны как хотя бы потому, что они делают блоки кода чище.
В виде должна быть логика представления (если это не Hello World). PHP-код — это как раз и есть логика представления. И ее должно быть ровно столько, сколько нужно. А верстальщики вроде должны шаблоны без логики делать, логика — задача программиста. Правда последнее утверждение может быть весьма спорным и наверняка найдутся куча примеров, когда программисты верстают или верстальщики пишут PHP-код в шаблонах.
Зачем разделять локальные и глобальные переменные в шаблоне я написал выше.
Как бы обращение к объекту подразумевает под собой динамику (объект — это динамическая сущность класса). Обращение к классу подразумевает статику («не меняется для каждого объекта»). Обращаясь за статическими свойствами к объекту вы вводите в заблуждение читателя. Я понимаю, что разница все равно есть (:: vs ->), но она становится менее заметной.
Есть один use case, когда такое может пригодиться. Когда мы не знаем, какого класса у нас объект, но хотим взять у него константу или статику. Но что-то мне кажется, что это больше «пахнет» ошибкой проектирования, чем реальной необходимостью…
Причем в данном случае, при внезапной нехватке места вы просто отдадите ошибку. И это ничего не поломает, так как пользователь обязан обрабатывать такие ошибки. В смысле, у пользователя ничего не упадет, в отличии от ситуации, которую вы описывали выше.
Вывод: такой сервис — хороший компромисс между резиновостью и качеством. А резиновые диски для виртуалок, на мой взгляд не нужны. Проблемы с большими перепадами требуемого места на диске нужно решать иначе…
Мне вот больше интересно было бы получить возможность выбора системы тарификации — шейпер и без оплаты за дисковые I/O или быстро, но с оплатой. Когда у меня возникли проблемы в некотором месте и деньги потекли рекой, было большое желание по-быстрому перейти на [не буду говорить кого, а то сочтете за рекламу]. Мне с моими проектами лучше бы медленный сервис и время на реакцию, чем скорость и дикие счета.
Вообще, я являюсь клиентов двух облачных компаний — Селектела и [не буду говорить кого, а то сочтете за рекламу]. Плюсы и минусы есть у всех. Поддержка мне больше нравится в Селектеле, панель у [...], тарифы в Селектеле ниже (если не учитывать косяки с I/O, из-за которых деньги улетают моментально… Падений давно не было ни у тех, ни у других.
Да, в первую очередь локальные переменные появятся в циклах. А вообще, в шаблоне могут быть вычисления (которые связаны с логикой представления), и их результатам самое место в локальных переменных.
Что касается избегания, то это как минимум ничем не обосновано. Локальные переменные нужны как хотя бы потому, что они делают блоки кода чище.
Зачем разделять локальные и глобальные переменные в шаблоне я написал выше.