Igor Deyashkin

Баланс.
Если проект реально высоконагруженный, но простой, как табуретка - то человек прав, чем меньше в коде будет абстракций, тем меньше оверхеда.
Но если проект не только высоконагруженный, но и сложный - вы мозг сломаете, делая его функционально. Функции хороши там, где нужны простые решения. Если вы можете разобрать всю архитектуру на простые решения - вам не нужно ООП. Если не можете - то без него проект захлебнется в собственной сложности.

Шаблонизатор шаблонизатору рознь. Но в целом следует выделить общие задачи. которые должны решать за вас шаблонизаторы. С blade не работал и не вижу смысла есть есть twig.

Безопасность. Это пожалуй можно поднять на верх. Типичная картина в шаблонах на php - <?= $someUserInput; ?>. Частенько это можно встретить в выводе инпутов, при формировании ошибок поиска (мол "по запросу $userInput ничего не найдено. То есть вставляем в инпут подключение наших js скриптиков, если это форма поиска - делимся с "другом" и забираем его сессию. Ну или еще какие забавные штуки можно делать. А ведь все очень просто решается. Ставим какую-то функцию, которая по умолчанию будет фильтровать XSS инъекции при выводе, и не будет этого делать только если мы попросим. Если писать просто на php - появляются отвратные функции, которые можно просто забыть вызвать. А с шаблонизаторами мы пишем красивые {{ someUserInput }} и можем спать спокойно.

Помогают соблюдать принцип DRY. Современные средства шаблонизации (twig например), предоставляют вам возможность разделять шаблоны на блоки, переиспользовать их несколько раз, выделять макросы, наследовать шаблоны... словом все что угодно. лишь бы вы могли реюзать куски html а не копипастить их.

Ограничивают полет фантазии разработчика. Далеко не новость что разработчики ленивые засранцы. Особенно молодые. Если им в шаблоне внезапно понадобились какие-то данные из БД, или данные связанные с запросом, большинство не будет париться и зафигачит нужный код прямо в темплейте. Так же некоторые грешат тем что часть бизнес логики размазывают по шаблонам. Так же встречал проекты отданные на суппорт, где чуваки в шаблонах разбирали через xpath ответы от сторонней апишки (которая использовалась вместо базы данных. То есть это дело было размазано по всему проекту). Рефакторинг в случае изменения апишки будет болью.

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

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

Так как за все эти приятные вещи мы по сути ничего не платим (шаблонизатор должен компилировать все это в нативный php так что оверхэда просто не будет), почему бы не пользоваться?

Нет

Для правки файлов использую WinSCP + sublime text 2
При сохранении файла, он автоматически заливается на сервер

Rebase как раз и сделает так что головой ветки experiment как раз и станет последний коммит m11 в master.

$ git init
$ echo 111 > 1.txt
$ git add .
$ git commit -m "m10"
$ git checkout -b server
$ echo ser >> 1.txt
$ git commit -am "s11"
$ echo ser1 >> 1.txt
$ git commit -am "s12"
$ echo ser2 >> 1.txt
$ git commit -am "s13"
$ echo ser3 >> 1.txt
$ git commit -am "s14"
$ echo ser4 >> 1.txt
$ git commit -am "s15"
$ git checkout -b experiment
$ echo exp1 >> 1.txt
$ git commit -am "e1"
$ git checkout server
$ echo ser5 >> 1.txt
$ git commit -am "s16"
$ git checkout master
$ git merge server
$ git checkout experiment
$ git rebase master
# будут конфликты, решаем их
$ git mergetool
$ git rebase --continue
$ gitk --all

Обычно сразу обращаю внимание на контактную информацию, наличие реквизитов.
По Whois смотрю дату регистрации домена. По возможности его историю, а также пр и тиц.
Гуглю отзывы.
Проверяю указанный адрес на соответствие по карте.
Если есть оффлайн магазин или офис тоже немаловажно.
Сверяю цену товара со средне статистической.
Если есть в Яндекс Маркете
Смотрю на общее оформление, например отсутствие непереведенных сообщений.
Если покупка дорогая, сначала заказываю безделушку.
Смотрю общий ассортимент магазина, не доверяю когда в магазине электроники есть трусы и хозтовары.
Один раз спасла exif информация в картинке, один раз не понравилось, что картинки не потрудились перезалить, а просто ссылкой с другого магазина.
А так же доверяю интуиции.

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

Так что или SAX Parser (http://se.php.net/xml) или XMLReader (http://se.php.net/manual/en/book.xmlreader.php)
Кстати, хорошо работает комбинированный подход: ищем место XMLReaderом и потом результат заргужаем в SimpleXML и работаем с ним как нормальные люди.

Сделайте тест, даже на 10Мб скорость будет заметна. Попробуйте загрузить даже такой файл в разные парсеры и офигейте от раздницы во времени работы и использовании памяти :)

Я бы сказал так:
Интерфейс — это возможность задать жёсткую семантику.
Абстрактный класс — это возможность вынести дублирующийся код и явно это отметить в иерархии.

Специалист по поддержке пользователей — Technical Support Engineer/Desktop Support Engineer;
Системный администратор — System(s) Administrator;
Сетевой администратор — Network Administrator;
Системный инженер — System(s) Engineer;
Архитектор — Architect (по областям, например Software Architect, Infrastructure Architect, и т.д.);
Ведущий инженер/Старший инженер — Senior Engineer;
Программист/Разработчик — Software Developer;
Тестировщик — Tester;
Руководитель проектов — Project Manager;
Руководитель группы — Team Leader;
Начальник отдела ИТ/Технический директор — Chief Technology Officer (CTO);
Руководитель информационной службы/Директор по информатизации — Chief Information Officer (CIO).

Разница между CIO и CTO (если упрощенно): CIO — человек бизнеса, который что-то понимает в ИТ, CTO — технический человек, который что-то понимает в бизнесе.

Увы, но если git не смог сам разрешить конфликт, то однозначно сделать это автоматически нельзя.

Взять только нужные изменения можно, если просто скопировать дерево v2 поверх дерева master, а потом записать только нужные изменения при помощи git add --interactive. Все же ненужное затем убирается через git checkout ., который сбросит состояние рабочего каталога в индекс (все, что добавилось через git add, останется).