Алексей Шеин

Читайте про магические методы.

class Foo
{
	public function bar()
	{
		var_dump('Foo::bar()');
	}
	
	public function __call($method, $args)
	{
		var_dump($method, $args);
	}
}

$foo = new Foo();
$foo->bar();
$foo->baz();
$foo->baz(true, 1);

string(10) "Foo::bar()"

string(3) "baz"
array(0) {
}

string(3) "baz"
array(2) {
  [0]=>
  bool(true)
  [1]=>
  int(1)
}

В вашем случае я бы ещё посмотрел в сторону баз данных.

Слишком много папок тоже плохо - чем больше вложенность, тем больше будет оверхэд по инодам. Всё зависит от файловой системы и от того, что вы понимаете под "очень много". По опыту скажу, что ext4 с множеством метаданных справляется быстрее остальных и скорее всего подойдёт для такой задачи, XFS наоборот хороша для хранения очень больших файлов - баз данных, например.

Есть ещё новая ФС - btrfs, она умеет держать метаданные для большой файловой системы на SSD дисках, а данные - на более медленных. Для больших хранилищ самое то.

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

events.linuxfoundation.org/slides/2010/linuxcon201...

См. также Какое максимально число папок можно создавать в папке?

Phing/Grunt/Gulp и т.д. это все аналог Make. Вы можете вместо phing make файлы писать, будет примерно то же самое, просто с phing возможно чуть удобнее. Вообще лучше не проецировать на phing ваш опыт общения с grunt. Оно как бы одно и тоже но чуть чуть отличается. Тут больше подходит параллель с ant.

<select name="my-select">
  <option>...</option>
  <option>...</option>
  <option>...</option>
</select>

// jQuery
var myDynamoSelect = $('select[name="my-select"]');

$.ajax({
    type: "POST",
    url: "some.php",
    data: "name=John&location=Boston",
    success: function ( data ) {
      // empty() чистим HTML в селект
      // html(data) вставляем в select то что ответил сервер (<option>...</option>)
      // пример ответа: <option>...</option><option>...</option><option>...</option>
      myDynamoSelect.empty().html(data);
    }
 });

поищите инормацию json - php - ajax

А зачем вам это нужно? Что бы пользователь не мог загрузить один и тот же файл дважды? А почему его нужно так ограничивать?

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

По хорошему это лишняя проверка, если только для этого нету веских оснований.

Проще всего сравнивать Composer c Bundler'ом.
Composer не является средством для деплоя или миграций типа Capistrano\Сapifony, его основной задачей является менеджмент зависимостей. Когда в либах находят дыры или правят баги и нужно быстренько обновить зависимости - лучше средства нет.

c.learncodethehardway.org
www.programmr.com/zone/cpp

Я бы посмотрел на это не со стороны php, а с javascript. Пусть Ваш javascript "спрашивает" (тем же ajax'ом) у веб-сервера данные, который в свою очередь, через php-скрипт вернет ему нужные данные. Лично я юзаю ajax от jQuery, все просто, и я доволен как слон :)

Жутко.

Если в lib у вас лежат библиотеки, то там код не должен быть привязан к конкретным данным, т.е. там либо список функций, либо классы.
А вот в каком месте вы их вызываете?
Ну и как вариант всегда в html передать эти данные

<input type="hidden" id="xxx" value="2" />

доработайте апи чтобы оно понимало запросы вида
api.site.ru/museums?city=spb&categories=museums&type=best

Считаю, что стоит в одном Gemfile выделить различные группы для каждого окружения (development и production). На локальной машине использовать development а на сервере production. Почитайте подробнее об этом здесь: bundler.io/v1.5/groups.html

You'll sometimes have groups of gems that only make sense in particular environments. For instance, you might develop your app (at an early stage) using SQLite, but deploy it using mysql2 or pg. In this example, you might not have MySQL or Postgres installed on your development machine, and want bundler to skip it.

Иногда у Вас может возникнуть необходимость использовать разные наборы гемов в разных окружениях. К примеру: вы разрабатываете приложение, используя SQLite, но при этом на сервере используете Postgres. В таком случае, Вам не нужно, чтобы Postgres устанавливался на локальной машине.

P.S. Перевод немножко упрощен.

git или mercurial. svn уже не совсем актуален

Книги Роберта Мартина — Clean Code и Agile Software Development: Principles, Patterns, and Practices

«Рефакторинг» Фаулера тоже полезен.

www.ozon.ru/context/detail/id/1308678/

Кроме отдельных веток, возможно вам подойдут submodules.