Станислав Почепко

У вас 3 сущности: User, Post, Comment.
REST подразумевает что к каждой из них можно обращаться обособленно от других.
Т.е., у вас будут роуты вида:
/posts
/posts/{id}
/users
...


Если вы делаете Single Page Application, то логично будет подгружать каждую из них по мере надобности (Да, в несколько отдельных запросов)

Но что бы не делать 3 запроса, вы можете подружать их все вместе, указывая что подргужать с помощью get параметров. Например:
/users?with=posts,likes

Свое API вы можете создавать сами и REST не панацея. Определенно, стоит знать его идеи, но вслепую следовать им не стоит.

https://github.com/psliwa/image-optimizer

Вариантов несколько:
- Реализовать свой Auth класс, который будет возвращать правильную модель через MyAuth::user() (но могут быть подводные камни)
- Реализовать свой UserRepository в котором будет методы auth/login/findByID/etc, и который будет возвращать правильную модель, и работать только через этот класс.
- Сделать 2 разные таблицы, и работать с ними отдельно. При авторизации пробовать авторизировать в каждой из таблиц.
- Сделать 1 таблицу для логина, и 2 дополнительных для остальной информации. Тогда можно логинить по 1 таблице, а затем брать нужную таблицу из relation.

Попробуй изменить подсеть тенды например 192.168.10.1-255,можно предположить чсто происходит конфликт айпишников,так как у них одинаковые подсети 192.168.0.1

Поменяйте `table` на название вашей таблицы, и скажите есть ли прирост в скорости.

SELECT tab1.`id`  FROM `table` AS tab1
  JOIN
    (SELECT
      (  RAND() * (SELECT MAX(id) FROM `table`) ) 
    AS id )
  AS tab2
 WHERE tab1.id >= tab2.id
 ORDER BY tab1.id ASC
 LIMIT 1;

двух-факторная авторизация работает только при логине по паролю.

генерируете ключ и добавляете его в настройках github - https://help.github.com/articles/generating-ssh-ke...
если дословно выполнили инструкцию, то на этом моменте все уже должно работать.
если использовали кастомное название файла, нужно немного магии с .ssh/config - https://gist.github.com/jexchan/2351996

есть еще способ с токеном, но я не в курсе как он работает с ide.

IMHO напрямую никак. строка не возникнет из неоткуда.
вот если сгенерировать "табличку" с датами и с ней сделать LEFT JOIN - тогда будут пустые строки (с NULL, не 0).
собственно, все что для этого надо - это таблица-справочник с датами.

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

Фасад - это способ к некому классу обратиться как к статическому. Для этого при "создании" (точнее регистрации) фасада регистрируется код создания экземпляра класса и дальше при вызове SomeClass::method() фреймворк создает класс SomeClass при помощи этого кода и вызывает метод method(). laravel.su/docs/5.0/facades

Сервис-провайдер - это класс, который осуществляет инициализацию некоторой части приложения Laravel - регистрацию фасадов, папки вьюх, конфигов, в общем, всего подобного. Хватило бы одного сервис-провайдера, но их много, потому что модуль, пакет или логическую часть приложения удобнее инициализировать в отдельном классе, а не дописывать все в существующий. laravel.su/docs/5.0/providers

Сервис-контейнер Laravel, при помощи которого (а не при помощи оператора new) создаются все классы во фреймворке, по сути не отличается от такого же фальконовского: laravel.su/docs/5.0/container . Он нужен для реализации DI, т.е. при создании некоторого класса, например контроллера, проходить по аргументам методов, смотреть, какие там подаются классы на вход, создавать экземпляры этих классов и собственно подавать их на вход.

Ну для начала — хранить шаблоны в моделях вообще неправильно. Про свои шаблоны должны знать только вьюхи.

Если у вас сборка организована с помощью browserify, то шаблоны можно компилировать на лету при сборку и во вьюхах писать просто типа такого:

render: () {
    this.$el.html(require('templates/template.jade')())
}

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

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

Фраза framework agnostic означает, что какое-либо решение не завязано на какой-то конкретный фреймворк и может завестись под любым (возможно, при помощи какого-то адаптера).

Прочитайте про связи: 1 к одному, 1 ко многим. много ко многим.
Таблица question_answer нужна для связи М-М, то есть когда одному вопросу принадлежит много ответов и один ответ может принадлежать многим вопросам. Судя по всему, это не то, что вам нужно, у вас вопрос-ответ это 1-М, то есть одному вопросу много ответов, но один ответ - это всегда только один вопрос. Связь 1-М делается так, как у вас в первом варианте.

Go отлично подходит для сетевого программирования. Сравнительно небольшие усилия нужны для написания довольно приличного клиент-серверного приложения (consul, etcd).

Кроме того, скорость и маленькое потребление памяти позволяют применять Go для обработки большого количества информации, подсчета статистики, написания парсеров/кравлеров. Тут очень сильно способствует возможность простого распараллеливания.

Go применяется для написания девопс и админских инструментов (Docker, CoreOS) которые легко использовать, так как все компилируется в один бинарник и линкуется статично.

А вообще, заходите к нам, читайте новости и будете всегда в курсе, для чего используется Go.