Алексей Уколов

С PHP.NET:

Связывает PHP переменную с именованным или неименованным параметром подготавливаемого SQL запроса. В отличие от PDOStatement::bindValue(), переменная привязывается по ссылке, и ее значение будет вычисляться во время вызова PDOStatement::execute().

Во втором случае в момент, когда происходит связывание переменная уже не существует. Попробуйте использовать bindValue.

Можно. К тому же, в MySQL есть специальный storage engine для логов.

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

1. Заголовок и описание.

<header>
    <h2>Заголовок</h2>
    <p>Описание к заголовку</p>
</header>

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

2. Несколько заголовков.

<hgroup>
    <h1>Титульный заголовок</h1>
    <h2>Подзаголовок</h2>
</hgroup>

Так как у нашей секции несколько заголовков разного веса, их так же стоит семантически связать. Для этой цели можно использовать hgroup, который, согласно спецификации, служит для группирования нескольких заголовков. Но, так как его убрали из спецификации, полагаю, эту роль возьмет на себя header.

3. Ваш вариант.
<h2>Заголовок</h2>
Заметьте, у вас всего лишь один элемент, который не требует группировки с чем-либо. Он самодостаточен, и по смыслу соотносится с секцией, в которой находится. Нет никакого смысла выделять ему дополнительный контейнер в данном случае.

Если коротко, то "быть". Это вам позволит избежать кучи граблей, на которые наткнетесь при разработке.

upd: Вот вам подборка для изучения https://github.com/instanceofpro/awesome-marionette

Запомнить, какие запросы были отправлены, и проверять:

var requests = [];
requests.push($.ajax({type: 'GET', url: '/echo/json/'}));
requests.push($.ajax({type: 'GET', url: '/echo/json/'}));
requests.push($.ajax({type: 'GET', url: '/echo/json/'}));
requests.push($.ajax({type: 'GET', url: '/echo/json/'}));
requests.push($.ajax({type: 'GET', url: '/echo/json/'}));

console.log(requests);

function Test(){
    $.each(requests, function(i, req){
        if(req.readyState == 0 || req.readyState == 4){
            console.log(req.status + ': ' + req.statusText);        
        }else{
            console.log(req.readyState);        
        }
    });
}

Test();

window.setTimeout(Test, 3000);

Посмотреть пример.
Можно удалять запросы из коллекции по завершению их выполнения.

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

Например, в output идет то, что возвращено из контроллера, а если возвратить ORM-объект или массив (точнее коллекцию) ORM-объектов, то будет отдан json, причем со всеми связанными объектами. Масса нужных в хозяйстве вещей, которые идут из коробки (миграции, редис, кэш с множеством провайдеров, работа с очередями, консольная тулза artisan для разнообразных обслуживающих вещей). Изкоробочная работающая сборка вьюх в лейаут, минимум возни с авторизацией. Скоупы в ORM. Кусочки конфигов в файлах, которые удобно ставить в .gitignore. В общем, масса такого вот, мелкого, но очень удобного.

На Laravel ОДНОВРЕМЕННО можно уйти в глубины аццкого хадкора по Фаулеру, с тестированием всего и вся, с интерфейсами, депенденси инжекшнами, репозиториями, обсерверами, ентитями, гексагональными сценариями итд, итп, _подставить_любимый_паттерн_, И в то же время забить на это всё, сгенерить _ide_helper для подсказок по "фасадам" в IDE и фигачить код со статическими вызовами, как будто весь фреймворк написан на статике, как Кохана. Т.е. и сайт-знакомому-за-вечер и огроменный кровавый энтерпрайз делаются на одном фреймворке - в зависимости от того, насколько глубоко исполнитель хочет погружаться в свой продукт. Подобная гибкость - это, имхо, очень круто.

И еще - как показала практика фреймворкостроительства, или ты двигаешься вместе с развитием php, либо ты делаешь "более лучшее, удобное и грамотное" решение и тихо загниваешь с своем междусобойчике за пару лет. Laravel двигается максимально близко к php - следование psr, composer-платформа в качестве базы, фрейморк ставится оттуда и пакеты расширения тоже имеют composer-формат. Что говорит о том, что у фреймворка есть все шансы прожить долгую и счастливую жизнь.