Матвей Мамонов

Наш опыт — не менять структуру УРЛ-ов!
Во-первых, переиндексация идет долго и мучительно.
Во-вторых, все равно в новом движке нужно помнить про старую структуру всегда, т.к. наверняка остались естественные ссылки на старые страницы, следовательно редирект должен корректно работать следующие 5 лет.
В-третьих, пользователям пофигу, они не вникают ни в длинные ни в короткие УРЛ-ы, Сафари вообще не показывает путь по сайту, только домен в строке адреса.

Композер - это всего лишь утилита, которая достаёт из чужого (или своего) репозитория какой-либо компонент. Затем:

1) скачивает его
2) ложит в папку с вендором
3) автоматически регистрирует автолоадер (PSR-0/PSR-4)

И делается это все одной командой. Можно конечно делать это всё вручную, но очень не удобно (а что если несколько библиотек / компонентов нужно подключить? - волокита и геморой). Причина популярности композера именно в этом. Например Laravel - он использует компоненты Symfony, следовательно при инсталляции он будет брать те самые компоненты с репозитория Симфони.

Здесь главное уловить суть - это сведение подключения сторонних компонентов и библиотке к одной команде. И да, там всего лишь простых несколько команд для этого.

Вдаватся в дополнительные подробности (например в синтаксис composer.json), здесь не имеет смысла, т.к это все есть на официальном сайте.

Тебе не с тестового сайта надо начинать, а с todo листа. В документации каждого фреймверка есть руководство по созданию простенького блога иди ещё чего-то в этом роде. Там описан весь процесс программирования. После того, как вы сможете сами этот "блог" написать не подсматривая в руководство (В документацию можно), то тогда вы и сможете что-то новое придумать. Вы поймете для чего нужны те или иные вещи в данном "конструкторе".

От тестовых сайтов проку ноль. Они ничему не учат

$arr = array(
    'title' => 'This is Title',
    'content' => 'This is Content'
);

$new_arr = array();
foreach($arr as $key => $value){
	$new_arr['{{'.$key.'}}'] = $value;
}

print_r($new_arr);

Идея ничего не стоит.
Стоимость имеет реализация идеи.

Продать идею невозможно -
Пока вы не озвучили идею - я не знаю за что я плачу, какой смысл мне отдавать деньги за кота в мешке?
Если вы озвучили идею - а зачем я должен вам платить? Идею я уже знаю. Вы же не можете доказать какие то свои права на идею? Значит идея уже моя.

Много ответов есть уже, лучше попробую идти рядом с вашими словами. Итак,
> Зачем мне создавать файл, контролирующий это, если я и сам могу контролировать то, какие методы у меня есть
Вы - это ваша голова, вы человек, не робот, ваш может не быть на работе например, или вы сами можете забыть, как у вас взаимодействуют части системы. Интерфейсы - это в общем-то тоже документация. И не нужно строго различать "чисто интерфейсы", и интерфейсы класса - те методы, которые у класса паблик - это точно такой же интерфейс, только он явно не отделен от класса. Когда у класса всего 3-4 метода, и все они связаны простой идеей, то и выделять ничего не надо. Когда у класса уже 10 методов, и среди них есть небольшие смысловые группы, то уже имеет смысл эти группы подчеркнуть. И, в конце концов, вместо каши из 10 методов, вы читаете следующее: class Graph : IEnumerable, IIndexable, IDrawable - и вы знаете, что ваш граф перечисляется, индексируется и рисуется. Это уже очень много информации, вы уже понимаете, как взаимодействуют части вашей системы.

> Может создано это для работы в больших коллективах? Но ведь тогда любой участник сможет поправить и интерфейс.
Да, совершенно верно, для больших коллективов. Нет, участник просто так не сможет поправить интерфейс, не побеседовав с остальными. В лучшем случае участнику придется поправить весь код, который "висит" на этом интерфейсе, в худшем - он в принципе ничего не сможет поменять, если интерфейс "публичный" и используется несколькими командами разработчиков. Классический пример - системы плагинов. Если к MS Word-у уже написано куча плагинов, то MS не может взять и просто так поменять ифейсы, не поломав совместимость. Хотя некоторые аспекты реализации - может. Потому что, как уже сказали выше, интерфейс - это ДОГОВОР. Чем БОЛЕЕ он стабилен, тем ЛУЧШЕ. Команды договариваются (!), создавая интерфейсы, чтобы потом было как можно МЕНЬШЕ конфликтов и разногласий, т.к. проблемы с интерфейсом затрагивают всех. Найдите любую команду от 30 человек, и вы увидите, насколько это все важно.

Еще две вещи напоследок:
1) интерфейсы из ОО языков лишь частный пример понятие интерфейса в жизни вообще. Вы же, когда покупаете SATA-диск, наверное рассчитываете, что сможете его подключить к своему компу? А с чего вы взяли? А, ну конечно, ведь на упаковке написано SATA - значит производитель соблюдает ДОГОВОР - интерфейс передачи данных;
2) необходимость в некоторых фичах языков сложно осознать в личных проектах и даже в маленьких командах. Это тоже как в жизни: свой дом, как говорится, должен построить каждый мужик, а чтобы построить бизнес-центр или высотку, нужны определенные знания, т.к. другие масштабы. Это нормально. Тем не менее, нужно читать и искать примеры. Хотя современные ОО-языки и сами дают много примеров. Раз у вас PHP, почитайте про Iterator например.

Лучше ответьте себе на вопрос: зачем писать свой шаблонизатор при наличии кучи готовых?
Если в академических целях - ok.
Если для реального использования - не стоит.

Ну а вообще понимаете правильно. Простейший шаблонизатор.
Шаблон:
<h1>{{title}}</h1>

Шаблонизатор:

class Template {
	private $data = [];
	
	public function set($name, $value) {
		$key = '{{' . $name . '}}';
		$this->data[$key] = $value;
	}
	
	public function get($name) {
		$key = '{{' . $name . '}}';
		return $this->data[$key];
	}

	public function render($fileName) {
		$source = file_get_contents($fileName);
		$build = str_replace(array_keys($this->data), array_values($this->data), $source);
		return $build;
	}
}

Использование:

$tmpl = new Template();
$tmpl->set('title', 'Hello');
echo $tmpl->render($templatesDirectory . 'main.tpl');

Приведу пример на коленке. Хотим, например, написать абстрактную файловую систему. Для начала, определим интерфейс, для ФС:

interface FileSystemInterface {
  public function write($file, $data);
  public function read($file);
}

Затем, хочу реализацию интерфейса ФС для работы с файликами:

class OSFileSystem implements FileSystemInterface {
  public function write($file, $data) {
     // открываем файлик, пишем данные
  }

  public function read($file) {
    // открываем файлик, возвращаем данные
  }
}

Вдруг, кому-то захотелось файловую систему в облаке. Окей, не проблема, реализуем это:

class CloudFileSystem implements FileSystemInterface {
  public function write($file, $data) {
     // открываем соединение с облаком, пишем данные
  }

  public function read($file) {
    // открываем соединение с облаком, возвращаем данные
  }
}

Пусть у нас есть кой-то код, работающий с файловой системой, назовем его "Хранилище файлов". Пусть он выглядит примерно так:

class FileStorage {
  protected $Fs;
  
  public function __construct(FileSystemInterface $Fs) {
    $this->Fs = $Fs;
  }  

  public function saveFile() {
    $this->Fs->write('file.txt', 'file data');
  }

  public function getFile() {
    return $this->Fs->read('file.txt', 'file data');
  }
}

Отлично! Теперь мы можем хранилищу файлов отдать любой объект с реализованным интерфейсом FileSystemInterface. Пример:

// Хранилище файлов работает с файловой системой ОС:
$FS = new OSFileSystem();
$FileStorage = new FileStorage($Fs);
$FileStorage->getFile();

// Хранилище файлов работает с файловой системой в облаке:
$FS = new CloudFileSystem();
$FileStorage = new FileStorage($Fs);
$FileStorage->getFile();

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

для веб-сервера апач

RewriteEngine on
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ page.php

Не знаю насколько интересно, но может кому пригодится. Частями найдено на просторах интернета, использую в своем template + normalize.
Заменяем длинный текст placeholder многоточием:

input[placeholder]          {text-overflow:ellipsis;}
input::-moz-placeholder     {text-overflow:ellipsis;} 
input:-moz-placeholder      {text-overflow:ellipsis;} 
input:-ms-input-placeholder {text-overflow:ellipsis;}

Скрываем placeholder при фокусе:

:focus::-webkit-input-placeholder {color: transparent}
:focus::-moz-placeholder          {color: transparent}
:focus:-moz-placeholder           {color: transparent}
:focus:-ms-input-placeholder      {color: transparent}

Курсор для label + отмена раздражающего выделения при клике:

label {
    cursor: pointer;
    -webkit-user-select: none;
    -moz-user-select: none;
    -ms-user-select: none;
    -o-user-select: none;
    user-select: none;
}

Только вертикальный ресайз для textarea (horizontal часто ломает диз):

textarea {
	resize: vertical;
}

Убираем дефолтный курсив у address:

address {
	font-style: normal;
}

Убираем подсветку полей:

input:focus,
textarea:focus {
		outline: none;
}

Адаптивные img:

img {
	height: auto;
	max-width: 100%;
	width: auto\9;
}

Адаптивные видео:

.video {
    position: relative;
    padding-bottom: 56.25%;
    height: 0;
    overflow: hidden;
}
.video iframe,  
.video object,  
.video embed {
    position: absolute;
    top: 0;
    left: 0;
    width: 100%;
    height: 100%;
}

Перенос слов:

.break-word {
        word-wrap: break-word;
}

Обнуляем списки глобально, т.к. часто используется для навигации и проч., в области контента можно задать другие стили.

ul {
	list-style: none;
	margin: 0;
	padding: 0;
}

Нумерованный список с подпунктами:

ol {
	counter-reset: list1;

	li:before {
		counter-increment: list1;
		content: counter(list1) '. ';
	}

	ol {
		counter-reset: list2;

		li:before {
			counter-increment: list2;
			content: counter(list1) '.' counter(list2) '. ';
		}

		ol {
			counter-reset: list3;

			li:before {
				counter-increment: list3;
				content: counter(list1) '.' counter(list2) '.' counter(list3) '. ';
			}
		}
	}
}

update дополнительно стили для печати

P.S. Что-то конечно юзается не всегда, по желанию лишнее удалить, замечаниям и критике буду рад.

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

В более сложных системах может быть использована проприетарная ОС. Иногда может быть даже что-то на базе *nix.

Наеример на компьютере Curiosity установлена операционная система реального времени VxWorks. Она же использовалась в других марсианских аппаратах: Spirit, Opportunity, Phoenix, Pathfinder и спутнике Mars Reconnaissance Orbiter, а также во многих земных роботах и встроенных системах.
Все программы Curiosity написаны на Си (НЕ С++, а обычный С)

php.net/manual/ru/function.explode.php