Boris Köln

Я расскажу Вам про личный опыт, без претензий на истину в последней инстанции...

Для чего идеальна MongoDb? Примеры приложений, где монга будет лучше mysql?

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

Если сравнивать с реляционными БД и с оглядкой на конкретно MySQL - монга идеально вписывается там, где структура данных заранее неизвестна. Тут я хотел привести пример, но не смог придумать ни одного дельного примера, после того как начал плотно работать с PostgreSQL... Давайте попробую из практики. Мы один раз применяли монгу в проекте где есть десятки и сотни тысяч товарных позиций и у каждой из них свой уникальный набор различных свойств. На основе уже имеющихся свойств, "соседних" товаров, контентщику предлагался наиболее вероятный набор параметров, которые нужно заполнить, но в любой момент он мог удалить или добавить любое поле и/или множество значений одного из них, например, "Цвет: черный, серый, фиолетовый". Всё это дело попадало под разные динамические фильтры и далее по цепочке... В то время, насколько я помню ещё не было поддержки JSONB-формата у PostgreSQL, по этому мы остановились на MongoDB. Ну и конечно же, желание "воткнуть ультра новую и модную БД в проект" сыграло свою роль...

Что в монге определённо не нравится (и это не моя "идея", об этом пишут даже в учебниках под монге) - это тотальная денормализация данных. Которая в некоторых случаях может сыграть злую шутку. Например, все комментарии "поста" обычно хранятся прямо в самой сущности поста. Это очень удобно и довольно быстро работает, но... иногда это приводит к полному коллапсу. Особенно, когда у Вас перекрестная ссылочность.

Безусловно, не редко можно встретить проекты в которых даже в реляционных БД не прописаны, например, внешние ключи и контроля целостности данных как такового нет, но обычно это происходит по следующим причинам:
1. Очень низкая квалификация администратора БД проекта
2. В попытке выжать из базы больше производительности, не найдя других методов оптимизации
3. Данных настолько много, что БД/ключи - начинают "сыпаться", не редко это связано с п.1

Так же, последние тесты показывают, что PostgreSQL почти не уступает MongoDB даже в её родной среде (на уровне данных в формате JSON). А в некоторых аспектах даже превосходит её... Подробности Вы можете увидеть на некоторых конференциях по Postgres (да, на конференциях по MongoDB, Вы вряд ли увидите, как кто-то будет рассказывать, что [их любимая] монга "хуже" некоторых других движков...). Кстати, поддержку формата JSON стандартизировали (наконец-то) на уровне SQL-стандарта (если я не ошибаюсь) и в самом ближайшем будущем, думаю стоит ожидать полноценную поддержку оного в SQL-базах, в т.ч. поддержку в бинарном виде с возможностью индексации данных (кстати, некоторые SQL-базы уже такое умеют).

Моё понимание, ответа на вопрос, "когда действительно стоит использовать MogoDB?" звучит примерно так: Исключительно в тех случаях, когда Вы понимаете, что она станет действительно хорошим решением для поставленной задачи и сейчас и в будущем. В моей практике, таких проектов можно было бы насчитать ничтожно мало, а точнее около нуля, особенно с учётом развития некоторых современных SQL-БД и вообще направления "JSON в SQL" в целом. Но, безусловно такие проекты могут быть и есть (в данном случае, не у меня). Но, тут стоит обратить внимание на крайне важный факт - когда всплывает такой проект, что бы адекватно оценить наиболее оптимальную БД под него - нужно знать как минимум пару-тройку SQL-БД, со всеми их особенностями, достоинствами и недостатками... причем не просто "знать", а хорошо знать, "изнутри". А так же знать все характерные черты монги, а так же её особенности, достоинства и т.д. То есть, если Вы задаётесь вопросом, "а хорошо ли впишется монга в проект N?" и не можете найти на него однозначного ответа, вероятнее всего, что в долгосрочной перспективе, в "проект N" она впишется плохо.

P.S. В заключение, хочу ещё раз напомнить, что "JSON в SQL" - активно развивается... Со всеми вытекающими.

это Payment api
https://www.w3.org/TR/payment-request/

Коротко: используйте только стабильные релизы при указании версий в зависимостях в своих пакетах.

Подробно.
В composer есть флаг minimum-stability, который используется для отбора пакетов на основе стабильности при установке. По умолчанию он равен stable, т.е. устанавливаются только стабильные пакеты. Вы можете изменить это поведение, добавив параметр "minimum-stability" в composer.json. Обратите внимание, что этот параметр применяется только к корневому пакету - вашему основному composer.json файлу.

Что происходит, когда вы вводите команду composer require nullref/yii2-cms:

• Создается composer.json файл, в котором не определен minimum-stability, поэтому он рассматривается как stable.
  
• В корневом пакете у вас определен в зависимостях только один пакет - nullref/yii2-cms, который имеет стабильный релиз - он и начинает устанавливаться.
  
• Пакет nullref/yii2-cms имеет в зависимостях пакет nullref/yii2-admin с версией dev-master. Это нестабильный релиз и он не может быть установлен, т.к. в корневом пакете minimum-stability считается равным stable.
  

Что можно сделать:

• Установить minimum-stability в dev в корневом composer.json файле. В этом случае также следует добавить "prefer-stable": true, чтобы по возможности ставились стабильные пакеты.
  
• Использовать stability flags, явно указав флаг в корневом пакете: "nullref/yii2-admin": "@dev".
  
• Убрать dev-master отовсюду из зависимостей, выпускать релизы и указывать версии любым из доступных способов.
  

И в заключение привожу ссылку на статью с подробным объяснением minimum-stability.

Можно без js обойтись, animate:

<div class="box">
    <svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width="300" height="300">
      <circle fill="none" stroke="#000" stroke-width="3" cx="150" cy="150" r="100" />
      <circle cx="150" cy="150" r="10" stroke="red"></circle>
      <g class="orbit">
        <circle cx="80" cy="80" r="20"></circle>
      </g>
    </svg>
  </div>

Анимация:

.box {
  height: 300px;
  width: 300px;
  background: #eee;
}

svg .orbit {
  animation: spin-right 10s 30 linear;
  transform-origin: 150px 150px 0;
}

@keyframes spin-right {
  100% {
    transform: rotate(360deg);
  }
}

пример codepen

Работал с ними немножко, идея такая - набирают много людей, люди учатся, сдают тесты, за каждый сданный тест тебе платят (от 5 до 50 долларов), потом если все тесты хорошо сдал, они приглашают тебя на них работать, за 15 долларов в час. Я сдал пару тестов по английскому, потом забил, времени не было, они закрыли контракт, поставили хороший отзыв. Заправляет всем этим индус из Стенфорда, по-моему, мне кажется это какой-то психологический эксперимент, типа хотят выяснить как людей мотивируют деньги)

Еще там перед началом работы надо заполнить нефиговую такую анкету, кучу времени занимает. По крайней мере, так было раньше.

Вы ошибаетесь, все эти сайты используют адаптивную верстку, она используется чтобы сайт выглядел хорошо на разных разрешениях, ориентациях и т.п.. Однако, адаптивная верстка малопригодна, если интерфейс на разных устройствах должен быть принципиально различен, например на десктопных версиях интерфейс заточен под управление мышью, на тач устройствах - на управление касанием, поэтому там принципиально другое расположение элементов и логика взаимодействия. Помимо этого, бывают устройства не поддерживающие media query и адаптивную верстку.
Поэтому, например, на mail.ru, например, есть десктопный интерфейс с адаптивной версткой, touch-интерфейс с адаптивной версткой, оба интерфейса отдаются с базовых доменов. Помимо них, есть отдельные интерфейсы на отдельных доменах без адаптивной верстки под браузеры с ограниченной поддержкой - light.mail.ru - для старых десктопных браузеров, m.mail.ru для старых смартфонов с поддержкой js, tel.mail.ru - для телефонов без поддержки джаваскрипта.

Ох и насоветовали вам, домен в listen...

Должно быть так (условно у вас ip=1.1.1.1)

listen	1.1.1.1:80;
server_name domain.com www.domain.com;

Или же, без привязки к ip адресу
Должно быть так (условно у вас ip=1.1.1.1)

listen	80;
server_name domain.com www.domain.com;

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

listen	80;
listen	443 ssl;
server_name domain.com www.domain.com;

Небольшая ремарка. Когда вы переходите по доменному имени в браузере, ваш браузер делает DNS запрос на NS сервер домена, спрашивает IP адрес из А записи указанного домена, после этого обращается на этот IP адрес по 80 порту и просит сервер отдать ему содержимое domain.com, если таковой имеется в конфигурации. Если домен все же сконфигурирован - веб сервер отдает содержимое document_root или того, что настроено, если нет - отдает клиенту содержимое первого сконфигурированного хоста в цепочке конфигов (его обычно конфигурируют без доменов, в document_root кладут пустой index.html).

Ремарка2. А учитывая то, что у вас за nginx работает apache, нужно не забыть сказать nginx'у откуда отдавать контент для данного домена.
В вашем случае, в "location /" должно быть как-то так.

location / {
        proxy_pass	http://127.0.0.1:81;
}