Виталий Хоменко

У вас выставлен Московский часовой пояс. Когда в Москве Новый Год 1970 года 00:00, в нулевом часом поясе еще 10800 секунд до этого момента, т.е.. 31 декабря 1969 года, 21:00. А когда в Москве 3 часа ночи, то в нулевом начинают праздновать и там равно 00:00.

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

Это не баг! Это фича! Дело именно в часовых поясах

Первая проблема - отсутствие нормального технического задания (ТЗ). Если там всё прописано по пунктам, спорных моментов практически не возникает, или их достаточно просто решить. Например, если изначально оговорена возможность правки SEO настроек сайта, а в финальном варианте самодельного движка такой функциональности нет, то это грубая ошибка разработчика и он несёт ответственность. В противном случае - это реализуется за отдельные деньги, с составлением нового ТЗ.

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

1. Если агенство (или просто команда) по созданию сайтов под ключ с помощью своего движка хочет ускорить и упростить технологический процесс для своих разработчиков, при этом полностью удовлетворяя потребности заказчиков в функционале.
   
2. Если проект делает один человек full stack, и в дальнейшем поддержка сайта будет полностью на нём.
   

А вообще, фрилансеру, который делает сайты в одиночку, нужно быть готовым к возникновению подобных спорных ситуаций. Это неизбежно и обусловлено тем, что заказчики, как правило, не имеют чёткого представления о том, как устроен сайт, какие есть нюансы в его разработке, поддержке и расширении функционала. И даже порой сами не знают, чего хотят, и зачем им всё это нужно.

Никак
Кантри менеджер ничем помочь не сможет. Поговори с клиентом и попроси его верифицироваться.
Еланс не закрывается а просто отребрендился после того как купил видимо за много миллионов долларов одеск
Ваши копейки там никому не нужны.

Чем куки отличаются от сессии в PHP?

в дополнение:
- сессии просто можно хранить в базе и тогда хэндлинг сессий это ваша забота. Это удобно когда у нас несколько серверов и балансировщик раскидывает нас на разные сервера, тогда у нас есть единый центр сессий например. Для этих же целей можно использовать memcache или redis.
- сессии не обязательно умирают после закрытия браузера

public function oauth($path, $parameters = array())

protected function _methodName()
{
    $connection = new \Abraham\TwitterOAuth\TwitterOAuth\TwitterOAuth(
         CONSUMER_KEY, CONSUMER_SECRET, OAUTH_TOKEN, OAUTH_SECRET
     );
}

ну и да, избавляемся от этого инклуда и выносим это в наш базовый автозагрузчик.

Доктор, когда я делаю вот так у меня болит. — А вы так не делайте

Потому что спецсимвол.

https://learn.javascript.ru/promise

Это делает утилита входящая в состав phpunit: skeleton generator. Если в шторме нет функционала работающего skeleton-generator можно поискать плагин, или просто можно генерить тесты через консоль. Если будут указаны аннотации то тесты будут созданы с реализацией методов.

но код, особенно после C++, не вызывает каких-то положительных эмоций.

А у меня не вызывает положительных эмоций код на C++. Да и код разный бывает. 90% кода на PHP у меня так же не вызывают положительных эмоций, но писать на нем нормально более чем можно.

1) под фразой "php умирает" позразумевает его модель работы. После каждого запроса он умирает, то есть воркер отчищается и запускается по сути заного. Это существенно упрощает работу (у вас хоть сегфлоты могут быть всеравно весь сервак не умрет), а так же масштабирование (за счет отсутствия у самого PHP состояния между запросами, сессии мы не берем в расчет), но существенно бьет по производительности. К счастью с PHP 5.3 писать демоны на PHP не так уж страшно.

Если же посмотреть рынок и динамику развития сообщества - PHP живее всех живых.

2) PHP не такой уж стремный язык. Я не считаю "не консистентные названия функций" таким уж прям фактором влияющим на выбор языка. С моей точки зрения Ruby уродливая отрыжка, попытка сделать объектно-ориентированный перл (это лично мое мнение, мне не приятно работать с ruby, пусть меня за это простят), но за счет того, насколько сообщество ruby-разработчиков ценит и понимает цели бизнеса, насколько уважает тестирование своих решений и т.д... словом PHP комьюнити в этом плане еще расти и расти. Но прогресс виден.

Да у языка есть просчеты, но их потихоньку сглаживают и устраняют проблемы.

3) нет. Шансов на нормальном уровне с нуля изучить еще один язык программирования и к тому же фреймворк - почти нет. Да и в этом нет смысла.

4) судя по вопросу вы уже определились для себя. Дальнейшая дискуссия не имеет смысла. Разбирайтесь. Но если брать шаред хостинги то PHP это пожалуй единственный адекватный вариант на сегодняшний день (если не брать в расчет что шаред хостинги как таковые это не очень адекватный вариант).

5) все зависит от вас. Хорошие разработчики зарабатывают примерно одинаково вне зависимости на каком языке программирования они работают. Они просто хорошие разработчики и таких всегда мало.

6) как хотите.

И так...

Язык программирования - это лишь инструмент для решения задач. Фреймворки - это так же просто инструменты для решения задач. Что важно - уметь задачи решать. И решать эффективно. Понимать что кривыми решениями вы увеличиваете риски для бизнеса.

Изучение языка программирование - это лишь десятая часть того, чем нужно владеть. При должном опыте вы сможете найти общие концепции, переносить знания с платформы на платформу, абстрагироваться от конкретных реализаций в контретных фреймворках и т.д.

Ruby например бизнес (и стартапы в особенности) выбирает не потому что это хороший язык, а потому что Ruby комьюнити в среднем больше приспособлено для эффективного решения задач бизнеса. Что говорить когда у них любовь тестирования прививают с первых дней знакомства с языком?

Не учите язык программирования. Учитесь разработке с применением этого языка. И тогда все будет намного проще.

p.s. Haters gonna hate

PhpStorm конечно же. Какие тут вопросы могут быть :)

php.net/manual/ru/language.variables.scope.php
функция не видит $get