Около трех лет вешал сайты на локальный хостинг, а сейчас работать стал так хреново - страницы прогружаются минутами, а иногда сайт вообще провисает. Короче говоря, решил съезжать. Рейтингам в интернете не особо доверяю, так как места там элементарно покупаются, ни для кого не секрет. Так что хотелось бы послушать реальные отзывы - какой хостинг стоит выбрать.

https://ru-php.livejournal.com/1572730.html

PHP 5.3.13

Такое впечатление, что PHP не знает разницы между GMT и UTC.
Unixtime базируется именно на шкале UTC, вместе с её секундой координации.
Однако же
$a = new DateTime('1992-7-1 23:59:59 UTC');
$b = new DateTime('1992-7-2 00:00:00 UTC');
print_r($a->diff($b));
Дает ответ 1 секунда, хотя правильный ответ - 2 секунды, ибо между ними еще "1992-7-1 23:59:60 UTC"

На самом деле расклад такой

UTC	Unixtime	GMT примерно
1992-7-1 23:59:58	710035198	1992-7-1 23:59:57.55
1992-7-1 23:59:59	710035199	1992-7-1 23:59:58.55
1992-7-1 23:59:60	710035200	1992-7-1 23:59:59.55
1992-7-2 00:00:00	710035200	1992-7-2 00:00:00.55
1992-7-2 00:00:01	710035201	1992-7-2 00:00:01.55

У кого-нибудь установлен 5.4 или старше? Проверьте у себя pls.

https://ru-php.livejournal.com/1572356.html

https://ru-php.livejournal.com/1572324.html

Вопрос на тостерре подтолкнул мою мысль, некоторое время уже работавшую в этом направлении.
И получилось у меня, что называем мы компоненты этого классического паттерна неправильно.
А правильно будет (по крайней мере, в случае с Ларавелью):

• Модели лежат в папке Controllers, при этом используя
  
  
  • ORM из папки Models для манипуляции с данными
  
  


• Визуальное отображение лежит в папке Views


• Секретарша лежит в routes.php.

И тогда всё сходится! Меня как раз смутили рауты в Ларавели, которые ничтоже сумняшеся используются в виде таких мини-рулетиковконтроллеров, которые берут на себя кучу задач - вплоть до авторизации!.
И меня давно уже смущало, что во всех фреймворках моделью называется тупо маппер таблицы из БД.

А вот если в голове названия переиначить, то всё сходится:
Раут - это тот самый тонкий контроллер, о котором все время говорили большевики, но который никто не видел.
Контроллер - это та самая толстая модель, которая отвечает за бизнес-логику!
Модель - ОРМ, которым и является.
Вью остаётся на месте.

Логично?

https://ru-php.livejournal.com/1571892.html

Перевод статьи A possible future to PHP Франка Карличека

Возможное будущее PHP

Согласно последней статистике, ownClowd – один из крупнейших опенсорсных проектов, написанных на PHP. Как многие из вас знают, PHP использован для серверной части ownCloud. Мы использовали другие технологии, такие как C++ и Qt для десктопных клиентов, Java для андроид-приложений и Objective-C для iOS-приложений, JS для веб-интерфейсов и т.д. Но сердце ownCloud – серверная компонента, использующая PHP 5.3 и выше.

Было несколько причин для выбора PHP:

• Миссия ownCloud – сделать возможным для каждого хостить его личный облачный сервер. PHP – технология, доступная на большинстве вебсерверов, операционных систем и платформ. То есть, мы сделали хостинг сервера ownCloud суперлёгким, потому что он написан на PHP.
  
• PHP – скриптовый язык, что означает, что один один серверный tar-файл будет работать на всех платформах без необходимости сложной кросс-компиляции и требования пакетов.
  
• PHP хорошо изучен. Множество людей хорошо знакомы с PHP. И даже разработчики, не знающие PHP, могут его легко выучить. Это очень важно для опенсорсных проектов, в которых порог вхождения должен быть как можно ниже.
  
• PHP быстр и производителен при правильном использовании. Множество больших веб-приложений вроде Википедии, Фейсбука, Вордпресса и частей Яху написаны на PHP. То есть, с этим языком вы можете сделать многое. К несчастью, на PHP так же легко писать плохие приложения. Об этом ниже.
  
• Для PHP существует огромная экосистема библиотек, компонент и драйверов. Для опенсорсного проекта вроде ownCloud это очень клёво потомму что это означает, что вам не нужно изобретать это с нуля. Мы стоим на плечах гигантов.

PHP – не самый хипстерский язык в мире. Даже наоборот, у него сравнительно плохая репутация. Я лично никогда не был большим фанатом выбора технологии на основе её клёвости или модности. Я думаю, разные технологии предназначены для разных задач, и делать выбор нужно объективно, без лишних эмоций. Так что я не понимаю религиозных дискуссий почему инструмент X всегда лучше, чем технология Y. Я думаю, все эти споры о правильной технологии возможны после определения курса (типа приложений - прим пер.).

Итак, я по сей день счастлив, выбрав PHP. До сих пор мы не встретили больших архитектурных технических проблем, которые нельзя было бы решить с помощью PHP.

Означает ли это, что PHP – совершенный язык и я супердоволен всем? Разумеется, нет. PHP был разработан в середине 90х, во времена, когда никто даже не представлял, как веб будет устроен сегодня. Некоторые из клёвых фич со временем сегодня превратились в кошмар. Много чего можно улучшить, и я думаю, даже разработчики ядра PHP согласятся со мной в этом.

Некоторые из очевидных недостатков:

• Безопасность. PHP сам по себе не является небезопасным, и, очевидно, возможно написать совершенные и безопасные приложения на PHP. Однако, PHP подходит к вопросам безопасности слишком легко, и не сподвигает разработчиков писать безопасный код. По правде говоря, в 90х все относились к безопасности беспечно. Так что в PHP немного возможностей, которые активно помогают вам писать безопасный код. С базами данных - путаница, из-за чего много людей до сих пор не используют prepared statements, что делает возможным sql-инъекции. Фильтрацию входных данных для защиты от XSS нужно делать вручную. Есть расширения и библиотеки для помощи во всех этих проблемах, но они не включены в язык.
  
• Время компиляции/конфигурация времени выполнения. Для прикола вызовите ./configure для компиляции php и посмотрите на опции компиляции. А затем посмотрите на все опции, которые могут быть установлены в php админом сервера. С одной стороны это клёво потому что админ может очень тонко настроить в PHP возможности ядра. Но для разработчика PHP-приложения, которое должно работать на всех PHP-серверах это кошмар. Вы никогда не знаете, какая опция включена или выключена. У нас в ownCloud есть много кода, который использует окружение и рантайм и проверяет, всё ли работает так, как ожидается, и если нет – адаптируется под него как необходимым образом. Это, увы, нельзя назвать стабильной платформой и хорошей абстрацией ОС.
  
• Некоторая неконсистентность в названиях функций и классов. Иногда нижние подчёркивания, иногда верблюжья нотация. Некоторые фичи реализованы через процедурный стиль, некоторые через ОО-API, а некоторые обоими способами. Нужно много чего подчистить.
  
• Статическая типизация. В целом это вопрос вкуса, но иногда я действительно хотел бы побольше статической типизации. Определите, что делает следующий код, если у вас в директории есть файл с названием “0”:
  while ( ($filename = readdir($dh)) == true) $files[] = $filename;
  

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

Последняя статья на ArsTechnica and Apples представила Swift как преёмника Objective-C, включившим мою фантазию, как PHP следующего поколения может и должен быть сделан. “Сохранить обратную совместимость программ или исправить их недостатки? – Apple Swift“.

Существует старый и простой подход. Разработчики ЯП выпускают новую версию с исправленными недостатками, несовместимую со старыми версиями. Примеры – Perl и Python. Проблема в том, что практически невозможно переписать большой программный проект, чтобы сделать его совместимым с новой версией. В конечном счёте вы оказываетесь вынуждены работать с двумя версиями ЯП/фреймворка длительное время. Иногда библиотеки и зависимости доступны только для одной из этих версий. Миграция суперсложна и не может быть сделана по частям. Взгляните на Perl 6 и Python 2/3 как пример возможного кошмара. Оба существуют долгое время и множество ПО застыло где-то посередине процесса миграции.

Намного более позитивным примером является C++. Этот язык по-прежнему сильно отличается от C, но хороший момент в том, что он может быть смешан внутри приложения. То есть, в 90х C-разработчики могли использовать клёвые новые фишки C++ в некоторой части приложения без необходимости переписывать всё с нуля.

Apples развивают Swift как наследника Objective-C по-моему мнению очень разумно. Это полностью новый язык, но он выполняется в том же рантайме. Это означает, что разработчик может взять существующий Objective-C проект и начать писать новые фичи на Swift или заменять куски один за одним кодом на Swift. Затем это компилируется в один бинарник, не имеющий новых зависимостей по сравнению с Objective-C.

Я хочу, чтобы PHP и дальше развивался и улучшался, но при этом давал возможность плавной миграции, не как Perl или Python, не давшие возможность полной обратной совместимости.

Таким образом, хорошим решением будет если PHP 6 или 7 добавят новый тег в начало php-файлов. Например, PHPNEXT вместо PHP. Чтобы оба способа полностью поддерживались новой версией PHP и могли быть использованы параллельно в одном приложении или даже одном файле. В секции NEXT дложен быть использован новый и улучшенный синтаксис.

Несколько идей для улучшений, который я бы с удовольствием увидел:

Базы данных. PHP поддерживает тонны различных API баз данных. Некоторые из них очень старые, и не могут быть использованы. Всё должно быть стандартизовано, и остаться только OO-интерфейс. Мне кажется удачным будет начать с PDO.

• 32/64бит. Всякий, кто пробовал писать приложения, которые работают на 32 или 64-битной ОС, понимал, что переменные, особенно целые, ведут себя по-разному. Я понимаю, что это отголосок C/C++, но это, вообще-то, плохая идея. Я не хочу иметь разные части кода, которые нужно независимо тестировать.
  
• Убрать safe_mode, open_basedir и прочие устаревшие подходы.
  
• Убрать большую часть опций компиляции и рантайма. Всё PHPNEXT окружение должно работать одинаково насколько возможно.
  
• Типизация. Будет круто, если PHP добавит опциональную статическую типизацию. Например, объявим переменную как bool или int. В противном случае должно быть брошено исключение.
  
• Всегда использовать юникод.
  

Некоторые из этих улучшений реализованы в Hack – форке PHP, выполненном facebook. Hack в самом деле интересный концепт который движется в аналогичном направлении. В нём так же есть тег "<hh", так что код может быть смешан в одном файле. На данный момент неясно, сколько сил вложит фейсбук в будущем в эту разработку и насколько эта разработка будет адаптирована за пределами фейсбук. Я особенно обеспокоен насколько они открыты для изменений, которые для них не важны. Я предпочту официальный и более общий шаг от PHP-сообщества, который будет одним из следующих мажорных PHP-релизов.

Я надеюсь, моя мечта о более новом и чистом PHP, включая плавную миграцию, станет реальностью, в следующие несколько лет.

Очевидно, мы в ownCloud не сможем начать миграцию на этот новый PHP пока 95% установок PHP не перейдут на новую версию. Это займёт ещё 3-5 лет.

С этими изменениями большие проекты вроде WordPress или ownCloud получат реальный шанс перейти на более новый и чистый язык. Но, что важнее, это сделает PHP готовым к вызовам будущего.

====

Комментарий переводчика:

Я перевёл эту статью, в основном, чтобы показать эволюцию типичного PHP-кодера.

Переиначивая известное выражение: программисты делятся на умных и упорных. Карличек, судя по этой заметке, является вторым и вряд ли первым. Человек, считающий некий инструмент с _врождёнными_архитектурными_недостатками_ неплохим только потому что он _распространён_, скорее всего только этот инструмент и знает. Если за годы практики он захотел не взять другой инструмент, а добавить сахара в прежний - значит он других инструментов не пробовал.

Очевидно, что софт, деплоящийся на VPS, может быть написан на любом языке, потому что его можно поставлять в tgz/git/deb/rpm/etc. При этом софт может установить свою копию интерпретатора со своими настройками (к вопросу о версиях PHP и php.ini). Фактически не было никакой необходимости ориентироваться на установленный в системе интерпретатор. Однако, Карличек пошёл по трудному пути, причём не просто трудному, а по пути ошибочного архитектурного проектирования. Чем это можно объяснить? Вероятно, только тем, что Карличек - упорный программист.

Такова эволюция типичных PHP-кодеров. С годами вместо того, чтобы слезть с PHP, они начинают его улучшать.

https://ru-php.livejournal.com/1571627.html

Сколько-сколько это у нас секунд в году, как вы думаете?

for($y=1970; $y<2038; $y++)
{
$y1 = $y+1;
$t = strtotime("$y1-01-01 00:00:00") - strtotime("$y-01-01 00:00:00");
echo "$y - $y1 = $t s =", $t/3600/24, " d\r\n";
};


1970 - 1971 = 31536000 s =365 d
1971 - 1972 = 31536000 s =365 d
1972 - 1973 = 31622400 s =366 d
1973 - 1974 = 31536000 s =365 d
1974 - 1975 = 31536000 s =365 d
1975 - 1976 = 31536000 s =365 d
1976 - 1977 = 31622400 s =366 d
1977 - 1978 = 31536000 s =365 d
1978 - 1979 = 31536000 s =365 d
1979 - 1980 = 31536000 s =365 d
1980 - 1981 = 31622400 s =366 d
1981 - 1982 = 31536000 s =365 d
1982 - 1983 = 31536000 s =365 d
1983 - 1984 = 31536000 s =365 d
1984 - 1985 = 31622400 s =366 d
1985 - 1986 = 31536000 s =365 d
1986 - 1987 = 31536000 s =365 d
1987 - 1988 = 31536000 s =365 d
1988 - 1989 = 31622400 s =366 d
1989 - 1990 = 31536000 s =365 d
1990 - 1991 = 31536000 s =365 d
1991 - 1992 = 31539600 s =365.04166666667 d
1992 - 1993 = 31618800 s =365.95833333333 d
1993 - 1994 = 31536000 s =365 d
1994 - 1995 = 31536000 s =365 d
1995 - 1996 = 31536000 s =365 d
1996 - 1997 = 31622400 s =366 d
1997 - 1998 = 31536000 s =365 d
1998 - 1999 = 31536000 s =365 d
1999 - 2000 = 31536000 s =365 d
2000 - 2001 = 31622400 s =366 d
2001 - 2002 = 31536000 s =365 d
2002 - 2003 = 31536000 s =365 d
2003 - 2004 = 31536000 s =365 d
2004 - 2005 = 31622400 s =366 d
2005 - 2006 = 31536000 s =365 d
2006 - 2007 = 31536000 s =365 d
2007 - 2008 = 31536000 s =365 d
2008 - 2009 = 31622400 s =366 d
2009 - 2010 = 31536000 s =365 d
2010 - 2011 = 31536000 s =365 d
2011 - 2012 = 31532400 s =364.95833333333 d
2012 - 2013 = 31622400 s =366 d
2013 - 2014 = 31536000 s =365 d
2014 - 2015 = 31536000 s =365 d
2015 - 2016 = 31536000 s =365 d
2016 - 2017 = 31622400 s =366 d
2017 - 2018 = 31536000 s =365 d
2018 - 2019 = 31536000 s =365 d
2019 - 2020 = 31536000 s =365 d
2020 - 2021 = 31622400 s =366 d
2021 - 2022 = 31536000 s =365 d
2022 - 2023 = 31536000 s =365 d
2023 - 2024 = 31536000 s =365 d
2024 - 2025 = 31622400 s =366 d
2025 - 2026 = 31536000 s =365 d
2026 - 2027 = 31536000 s =365 d
2027 - 2028 = 31536000 s =365 d
2028 - 2029 = 31622400 s =366 d
2029 - 2030 = 31536000 s =365 d
2030 - 2031 = 31536000 s =365 d
2031 - 2032 = 31536000 s =365 d
2032 - 2033 = 31622400 s =366 d
2033 - 2034 = 31536000 s =365 d
2034 - 2035 = 31536000 s =365 d
2035 - 2036 = 31536000 s =365 d
2036 - 2037 = 31622400 s =366 d
2037 - 2038 = 31536000 s =365 d


PHP Version 5.3.13
Windows NT MIKE 5.1 build 2600 (Windows XP Professional Service Pack 3) i586

"Olson" Timezone Database Version 2012.3
Timezone Database internal
Default timezone Europe/Moscow

Да ети же твою мать!
19-ое января 2011 года по его мнению содержит 82800 секунд = 23 часа.
А в какие-то дни - 25 часов.

Косяк ошибок с 1981 под 2011 годы, в основном - апрель и сентябрь.

На другой системе все корректно считается.
PHP Version 5.2.17
System FreeBSD NQ_meteodata 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:15:25 UTC 2012 root@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386

"Olson" Timezone Database Version 2011.13
Timezone Database internal
Default timezone UTC

https://ru-php.livejournal.com/1571571.html