MegaMufa

Разнесите создание инстанса и его использование.

class BarFabric
{
  public function create(array $config = [])
  {
    return new Bar($config);
  }
}
class Foo
{
  protected $barFabric;
  public function __construct(BarFabric $barFabric)
  {
    $this->barFabric = $barFabric;
  }
  public function someMethod()
  {
    $bar = $this->barFabric->create();
    $bar->method1();
    $bar->method2();
    $blabla = $bar->getResult();
    //etc
  }
}

class FooTest
{
  public function testSomeMethod()
  {
    $bar = \Mokery::mock(Bar::class);
    // ... описание поведения для мока
    $factory = \Mokery::mock(BarFactory::class);
    $factory->shouldReceive('create')->andReturn($bar);
    $foo = new Foo($factory);
    $this->assertSomething($foo);
  }
}

О том, как быть с ActiveQuery...

Во первых, выносите логику запроса так же в отдельный класс. Если генерируете новую модель, Gii это может сделать и сам.

class FooQuery extend ActiveQuery
{
    /**
     * @inheritdoc
     * @return Foo[]|array
     */
    public function all($db = null)
    {
        return parent::all($db);
    }

    /**
     * @inheritdoc
     * @return Foo|array|null
     */
    public function one($db = null)
    {
        return parent::one($db);
    }
}

Этот объект передавайте в целевой класс так же как фабрику:

class Bar
{
  protected $query;
  public function __construct(FooQuery $query)
 {
    $this->query = $query;
 }

 public function someMethod()
 {
    $foo = $this->query->where(...)->one();
    $foo->doSomething();
 }
}

Ну а дальше мокайте как и в первом случае

$queryMock = \Mockery::mock(FooQuery::class);
$queryMock->shouldRecieve('where->one')->andReturn($fooMock);

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

$fooMock = \Mockery::mock(Foo::class.'[save, update]');
$fooMock->shouldRecieve('save', 'update')->andReturn(true);

Relations можно не подменять вообще. Они прекрасно подставляются через ActiveRecord::populateRelation().

$foo = new Foo();
$foo->populateRelation('bar', new Bar());

Половина ответа, как сделать нормальное форматирование "налету" в отладчике хрома:

Я вижу по крайней мере 2 варианта.
1) При редиректе добавить к URL параметр или хеш. Во второй части скрипта считывать параметр в условии.
2) Перед редиректом записать параметр в куки или localStorage и после редиректа считывать параметр в условии.
P.S. Если страница редиректа другая, то вообще никаких проблем.

Учите сугубо ИТ английский.

Открою секрет.

Сидите часто на stackoverflow и читайте самые популярные вопросы и ответы от крутых разработчиков (владеющих отличным английским). Там легко понять уровень английского по ответам и вопросам. Это поможет не только "вариться" в своей среде, но и "вариться" по-английски. Запоминайте структуру сложных вопросов. И как они вообще подготавливаются. Далее смотрите, как на них отвечают. Зачастую, всегда просят описать задачу. Что, собственно, на самом деле и происходит на фрилансе. Далее, просят уточнить некоторые моменты. Затем постят свои решения с описаниями. Тут тоже нужно уделить внимание на подготовку ответа. Часто, конечно, это просто код)), но вам никто не запрещает, к примеру, спросить уточнения (не для понимания кода или алгоритма, а для понимания того, как разработчик будет разжевывать вам ответ на английском ;-)), если самолюбие позволяет)). Можете даже выписывать отдельные словосочетания, которые они применяют. К примеру, создал массив, присвоил значения переменной, пробежался циклом по массиву, создал класс, имплементировал интерфейс, перегрузил чего-то там и так далее.

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

не стоит удивляться: в таких вакансиях расставляют требования точно так же как и вы теги к своему вопросу.

держи примеры davidwalsh.name/css-flip

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

вопрос в другом, если у тебя большой поток, то как себя поведет ангуляр тебе могут сказать только гуру. Не спеши привязывать себя к фреймворку - лучше сделай прототип и посмотри как он работает в твоей схеме. Желательно сразу на второй версии или хотя б с использованием ES2015
Задумка Ангуляра в том, что он позволял верстальщикам делать интерактивность просто.

3. Можно упороться и сделать на Erlang

whatsUp не упоролся, а просто сделал и держит фб. Главное, что платформа берет на себя много вопросов по обслуживанию кода на множестве нод. И что твой код не уронит всю платформу при апдейте
Насколько я понимаю у го такой платформы нет

Вообще говоря быстрее/удобней таки на nodejs.

Если ваша цель - получить проект, который вы хотите быстро - пишите бизнес логику на PHP, для websockets юзайте habrahabr.ru/company/mailru/blog/266017/.

Можно линк на ваш проект?

Как не парадоксально, но ответ на вопрос имеет биполярный подтекст...

Вариант 1 (негативный)
У соц. сетей очень развита болезнь "сайта знакомств", когда % оттока посетителей, практически, равен приросту. И, на данный момент, это связано с тем, что рынок имеет полный ассортимент социальных сервисов (за исключением "экстраординарных").
Да, есть возможность переманить к себе часть пользователей от Спрашивай.ру (где, примерно, 5М посещений в месяц), ask.fm (где, примерно, 75М посещений в месяц) и nekto.me (175К в месяц) + VK / Facebook / Twitter. Но, необходим какой-то удерживающий фактор, который не позволил бы им так же и уйти.
Большинству людей сложно менять свои привычки (а еще, сервисы к которым они привыкли, где у них уже налажена своя экосистема).

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

В этом варианте, я описал основной негативный момент, который может не дать развить то, без чего соц.сеть не может существовать - критическая масса постоянных пользователей. Но есть и еще один маленький нюанс. Будет очень трудно привлечь внешнее финансирование. Это связано с тем, что сейчас инвесторы и бизнес-ангелы уже меньше верят в "очередной фэйсбук". Так что, 80/20, что придется самим все вытягивать... до определенного момента.

Вариант 2 (позитивный)
Очень хорошо, что Вы признаетесь сами себе, что первый блин вышел комом. Я уверен, что уже многое пересмотрено; и в плане дизайна и юзабилити, все будет в разы лучше. То, что за 3 года идея не умерла, так же, является хорошим знаком.

Ваша идея, если она будет реализована хотя бы в пилот, имеет и сегмент, и рынок для развития. Но, Вам будет нужна очень сильная команда. И это не помпезное высказывание, а практицизм на все 100%. Так как переманить к себе людей будет очень сложно (смотрите, Вариант 1) + продвижение должно быть во всеуслышание (максимальный масштаб).
Здесь несколько раз говорили о трудности монетизации. Не стоит переживать по этому поводу. Получить доход можно абсолютно из всего, и тем боле, из социальной сети, чем бы она не занимала людей. И думать нужно в первую очередь не о том, как заработать, а о том, что будет нужно/важно посетителям, да чтоб на столько, что они будут приходить снова и снова. Система мотивации, геймизация или еще что-то... но нужен очень хороший крючок.

P.S. Я думаю, что Вашу идею нужно реализовывать. Сделайте пилотную версию, пока не попробуете, ничего не поймете. Это в любом случае принесет Вам ощутимую пользу.

Попробуйте поиграть со свойством transform-origin и допишите свойство transform, например так:

.front .front_label h1 {
    font-size: 15px;
    transform: rotate(-90deg) translate(-100%, 0);
    display: inline-block;
    width: 154px;
    transform-origin: 0 0;
}

1. Параллельные потоки загрузки и обработки данных
2. Управление уровнем ошибок для продолжения или прерывания обработки ресурса.
3. Обработка и сегментация данных из ошибочных и неверных структурированных данных (например, HTML/XML).
4. "Решето" (правила) для предотвращения дальнейшей обработки ресурса на основе уже полученных данных (условия алгоритма прописываются в конфиге).
Например, контент размером более 5 кб со словом "toster" или url содержит "toster.ru" - пропустить и перейти к обработке следующего.

Вот, собрался списочек ссылок в тему:
www.pixate.com
https://wireframe.cc/
www.invisionapp.com
www.balsamiq.com
www.axure.com
www.justinmind.com
https://precursorapp.com/
giveabrief.com
avocado.ideo.com
www.appcooker.com
https://popapp.in/
www.pixate.com
https://marvelapp.com/
https://www.flinto.com/
framerjs.com
https://www.ux-app.com/
www.digitaltutors.com/tutorial/1959-Developing-Rap...
habrahabr.ru/company/aiken/blog/129653
keynotopia.com
https://proto.io/
https://codiqa.com/
https://gomockingbird.com/home
uxpin.com
www.pentotype.com
www.cooper.com/prototyping-tools

потому что ветка test создана на базе коммита, где уже была эта строчка, и когда происходил мердж, коммитов более поздних, затрагивающих эту строчку небыло. А значит - никаких конфликтов.

Если хотите получить конфликт - после того как закоммитите изменения в ветке test, вернитесь в master, поправьте ту же строчку, закоммитте и потом пробуйте мерджить.