Pull to refresh
21
0
Eugene Leonovich @gen

rybakit

Send message
PS. Если сделать стены разной высоты в SweetHome3D как на картинке выше, то для программы это будет уже не наклонная стена, а наклонный потолок, и в него уже не вставишь окно.
Про разные высоты я знаю, это не то, что мне нужно. Я имею в виду что-то типа этого:



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

Плюсы:

  • Возможность задать стороны света при проектировании дома. Полезно при рендере — можно посмотреть, как будут освещаться комнаты в разное время суток (естественным светом, дополнительно можно включать/выключать искуственное освещение);
  • Виртуальная прогулка по комнатам;
  • Возможность нарисовать стены обводя заранее импортированный план дома/кваритры;
  • Возможность импорта 3d-объектов разных форматов.

Единственный для меня существенный минус — нельзя создавать наклонные стены. У вас, как я понял, с этим тоже беда? Ну и вышеперечисленных плюсов при беглом просмотре я тоже не нашёл. Поправьте, если ошибся.
Не силён в Yii, объясните, чем не подходит такой вариант:

layout.html.twig
{% block javascripts %}
<!-- global js files -->
{% endblock %}


page.html.twig
{% extends "layout.html.twig" %}
{% block javascripts %}
    {{ parent() }}
    <!-- page js files -->
{% endblock %}
А теперь давайте пример с наследованием, автоматическим экранированием и сандбоксом. Шаблоны компилируются в нативный php, так что оверхед не такой большой, как вам кажется. Если же в вашем приложении шаблоны действительно являются узким местом, попробуйте Си расширение.
Поймите меня правильно, я за то, чтобы использовать @ с умом и крайне осторожно. В 99.9% случаев можно обойтись без подавления. И date(z) как раз тот случай. В то время как подавление ошибки может скрыть куда более серьёзные проблемы. Например, подавление вызова функции, которая поставляется с каким-нибудь расширением. Подавив эту ошибку, может быть очень трудно выявить, что причина некорректной работы приложения в недоустановленном расширении. Не говоря уже о том, что операция подавления не из дешевых.

Касаемо вашего примера:

Зависит от того, чем является удаляемый файл для приложения и как ошибка при удалении повлияет на дальнейшую его работу. В одном случае хватит и @, потому что, по-большому счёту, приложению не важно, удалится этот временный файл или нет, и смысла логировать эту ошибку нет. В другом случае ошибка удаления может быть критической и нарушить дальнейшую логику работы, тогда я бы написал что-то типа:

if (true !== @unlink($file)) {
    throw new \RuntimeException(sprintf('Failed to remove file %s.', $file));
}


Но и тут я использовал @ потому, что сообщаю приложению об ошибке посредством исключения и дублировать эту ошибку нет смысла.

Но, всё-таки, сравнение тут unlink($file) и date(z) не совсем корректно — это разного рода ошибки.

По-сути, работа с файлами/ресурсами — это, навероное, единственный пример, где использование @ ещё как-то оправдано, и мне трудно придумать кейс, где бы это было ещё уместно.
То есть вы хотите сказать, что этой проблемы бы не было, если бы логирование в пхп было отключено или все ошибки подавлялись бы @? Как я понимаю, вы логи вебсервера тоже отключаете, они ведь тоже могут вызвать ошибку файловой системы? Ваша приложение тоже ничего не логирует?
Да, я в курсе. Но error_handler с таким же успехом может обрабатывать и ошибки без подавления. А писать обработчик только для того, чтобы обрабатывать подавление @ выглядит извратом.
Это тоже самое, что сказать на следующее утро после серьёзной попойки, что конфета была лишней, потому что от неё сегодня болит голова.

Может всё-таки следовало настроить сервер?
Код с подавлением ошибок ещё больший говнокод, чем код, генерирующий эти самые ошибки.
Потому как неподавленные ошибки можно не показывать, но логировать. В случае же использования @ вы рискуете провести много весёлых часов/дней/недель, вылавливая баги «неговнокода».

Так что, либо оптимизировать по полной без @, либо писать правильно:
<?=date('z')-255?'':'С днём программиста';
Если мы всё-таки меряем количество символов, то для случая с нотисами и числами самый короткий вариант такой. Чтобы избавиться от чисел можно вставить U+2002 между ?:
А что, по условию задачи нельзя менять дефолтные значения в php.ini? Если да, тогда код

<?=date('z');


тоже будет генерировать ошибку, так как по-умолчанию data.timezone в phi.ini не задан и

Every call to a date/time function will generate a E_NOTICE if the time zone is not valid, and/or a E_STRICT or E_WARNING message if using the system settings or the TZ environment variable.
для чистоты устанавливаем
display_errors = Off
в php.ini
мы оптимизируем количество символов или размер файла?

лайт версия:

<?=date(z)-255?:С_днём_программиста;
убираем скобки, знак пробела заменяем на символ U+2002

<?=date(z)-255?:С днём программиста;
Тогда наверное нужно уточнить, что ваш код для версии <= 2.0.0beta-1, которая вышла почти год назад. Не пойму, статья была написана в тоже время? Потому как с beta-2 уже нет _sendMail(), a 3 дня назад уже вышел rc7.
P.S. В примерах я использовал Zend Framework 2.0, которая на момент написания статьи ещё находится на стадии бета-тестирования. Если вы работаете с версией 1.*, то нужно переименовать классы ...


Вы уверены что этот код работает в zf2? Что-то я не нахожу public function _sendMail() {… }
в Zend/Mail/Transport/Sendmail.php.
Слабое место тут как раз не столько в использовании pure php, сколько в том, что нет никакой обработки критических ситуаций. Например, как уже спрашивал markPnk, что будет, если отправка письма вдруг заняла больше минуты? Или что будет, если скрипт умрёт после того как mail() отработала, но запись ещё не удалилась из базы? Или письмо было отклонено почтовым сервером?
Видимо, EugeneOZ имел в виду вот это:
Property names SHOULD NOT be prefixed with a single underscore to indicate protected or private visibility.

Information

Rating
Does not participate
Location
Нидерланды
Date of birth
Registered
Activity