Иринка

1. Семантика на нуле. Header, footer, nav и пр. отсутствуют
2. Названия классов есть плохие (title, name, ten и пр.) – пространство имен и все такое. Ten – по названию нифига непонятно к чему это может относиться.
3. Пункты меню в html написаны капслоком, а если передумает владелец сайта, нужно будет менять текст. Есть же text-transform: uppercase
4. В css если значение 0, то пиксели можно не писать.
5. Валидатор - validator.w3.org/check?uri=http%3A%2F%2Fcolorkid.r...
6. padding-top:5px; padding-bottom:5px; Такое можно писать короче - padding: 5px 0;

1. <meta="utf-8"> - не правильный тег. Правильно: <meta charset="utf-8">
2. Далее неплохо было бы указать <meta name="description" content=""> Так как он учитывается поисковиком.
3. Ссылкам и изображениям необходимо прописывать title и alt. Почитайте про их употребление.
4. Старайтесь избегать смешивания чисто английских названий классов и русских транскрипций навроде <ul class="categoriimenu">. Стремитесь к единообразию структуры.
5. Используйте семантические теги html5 - header, footer, section, nav и так далее.
6. В целом для первого раза - неплохо. Удачи!

Пойдет?
codepen.io/aliencash/pen/pJbgzm

Изучите тему "системы счисления". Потом "арифметические операции в различных системах счисления". А дальше все будет понятно.
вот, например, book.kbsu.ru/theory/chapter4/1_4_10.html по операциям.
(в вашем случае будет 62-ричная система счисления.)

Фикстуры - это по сути тестовые данные. Они нужны для unit-тестирования. Это могут быть как данные в базе, так и обычные файлы (обычно 2 варианта, до и после обработки так скажем). Каждый раз когда запускаются тесты, эти данные используются для установления начального состояния системы, что бы тесты всегда выполнялись предсказуемо.

Для функционального тестирования (тестрирование контроллеров, интаграционных тестов) фикстуры не применяются, хотя суть там так же сходна. Если честно, то тут мнение расходится. Одни говорят что при функциональных тестах нельзя использовать даже моки, то есть система в процессе выполнения тестов полностью создает то состояние которое необходимо для других тестов. Например последовательное выполнение тестов на добавление статьи и ее просмотр. Другие же предпочитают для каждого тесткейса выставлять состояние с нуля. По сути это схоже с использованием фикстур, но реализация различается. У вас есть некое api для заполнения данными (скажем метод добавляющий пользователя), и перед выполнением тест-кейса происходит ресет данных и заполнение их новыми. Плюсы так же есть - можно распаралелить выполнение тестов. (но не верьте мне на слово)

Миграции - механизм организации версионности структуры проекта. Вы можете написать миграцию для изменения местоположения статики (картинки, поменять ссылки в базе и т.д.), или же у вас добавляется новая таблица/поле. Обычно дополняется обратной миграцией, которая восстанавливает исходную структуру. Обязательно для работы в команде или при частом изменении организации данных в проекте, вообще я бы посоветовал использовать их всегда.

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