hbuser

Скажу кратко: эффективный лендинг с точки зрения:

1. SEO/ПС: это много релевантно-семантического текста в скрытых блоках, которые могут читать пользователи после развёртывания (спойлеры, вкладки, аккордионы, слайдеры и прочее). Тексты формируются так, чтобы страница лендинга содержала максимальное количество целевых поисковых запросов, включая синонимы.

2. Аудитории (потенциальные клиенты): WOW-эффект, стильный вид, уникальность товара или услуги на рынке, удобство навигации, новшества в товарах/услугах, низкие цены, высокие гарантии, "прозрачность" и полнота информации, возможность выбора (модели, цвета, тарифы, бандлы, компектации и т.д.), известность бренда и т.д.

Первое. Кто сказал, что лендинг не для органики как принцип? Можно пускать лэндинг в СЕО, если лэндинг постоянный, а не на неделю под одну акцию. И, кстати говоря, иногда результаты СЕО для лэндингов гораздо выше чем для многостраничников, ибо мусора мало. Ну это так, к слову. Если вы решили ваш Лэндинг по СЕО не двигать, а ограничиться только контекстом, том никакой оптимизации под ключи делать не надо и вы правы - юзер пришел по контексту, а задача лэндинга взять за я... и удержать (в качестве первого этапа, как правило взять лид. Особенно если это не торговля китайской копией вьетнамских часов).

Второе. Наличие поисковой оптимизации не требуется, но смысловая связь с вашими обьявлениями в контексте быть обязана. Если юзер пришел по "Дешевая мебель на заказ" и первое что увидел - "Диваны категории Люкс" - вы потеряли деньги. То есть до сгиба юзер должен увидеть подтверждение того, по какому ключу он пришел.

Третье. Да, вы правы - ключевики это и есть семантическое ядро. На тему "как собрать практически" в принципе куча материала в инете, достаточно погуглить. Общий принцип простой - идем на вордстатс, сеопульт или еще куда-нить и начинаем собирать ключи. Придумываете несколько ключевых фраз за клиента и разворачиваете в инструменте. Например "Купить мебель" смотрите во что разворачивается и особое внимание уделяете НЕПОДХОДЯЩИМ запросам (ну к примеру купить мебель для куклы барби, приму в дар мебель, фото, видео, рефераты, своими руками и прочий нецелевой траффик). Всё это аккуратненько в минус слова готовите. Откройте какойнить эксельчик и по каждой категории (ну для лэнда это не очень важно, там как правило 1 категория, но тем не менее) собирайте разворачиваемые ключевики. Высокочастотники старайтесь отсечь, разворачивайте их вглубь. Вряд ли тратить деньги на запрос "купить мебель" целесообразно. Фокусируйтесь на нише. Ну и параллельно пополняйте минусовку. Чем больше минус слов соберете, тем больше денег сэкономите.
Вот собственно и всё. Чем больше дешевых низкочастотников и стоп-слов вы соберете, тем эффективнее и дешевле будет реклама. Обязательно прорабатывайте сопутствующие области. Например для продажи мебели мне с ходу видится посмотреть в сторону "ремонт квартиры", "переезд" и тому подобное.

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

Если коротко, то как-то так -))

Дополняющие - это размытое определение.
Есть: "аксессуары к ", "сопутствующие", "похожие", "с этим товаром также смотрят", "с этим товаром также покупают", "вы уже смотрели", "самое просматриваемое в категории", "новинки категории", "самое покупаемое категории".
Что интересует?)

Вот, собрался списочек ссылок в тему:
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

Ваш вопрос по семантике сходен с вопросом - "на каком языке писать самые красивые стихи?". Парадокс - это можно делать на любом. Красивые и удобные интерфейсы делает не язык, а дизайнер интерфейсов,верстальщик и программист. Язык выполняет роль инструмента. Безусловно хренячить красивый GUI на Assembler - задача не тривиальная, но это вопрос выбора инструмента. Вы где хотите интерфейс? В вебе? тогда js-фреймворки наиболее опитмальны. Настолки ? Qt или WinJs/WPF(для Windows-платформы). Мобильная разработка? Xamarin(если сразу писать на все платформы) или целевые фреймворки(Swift, Obj-C) под каждую платформу отдельно.

c++ + qt qml

Я у себя применял подход, взятый у гема CanCan из RubyOnRails.

Идея такова: определяем trait Ability и добавляем ему к классу User. Сам этот trait имеет метод can, который разрешает/запрещает определенное действие:

<?php

trait Ability
{
    public function can($verb, $noun)
    {
        $class = is_string($noun) ? $noun : get_class($noun);
        if(is_callable([this, "canManage$class"]))
        {
            $this->{"canManage$class"}($verb, $noun);
        } else {
             $this->fallback($verb, $noun);
        }
    }

    public function canManageUser($verb, $noun)
    {
        switch($verb) {
            case 'create':
                return true;
            case 'edit':
                if ($this->isAdmin()) return true;
                if ($noun->id == $this->id)  return true;
                break;
            case 'delete':
            case 'destroy':
                if ($noun->id == $this->id) return false;
                break;
        }
        return $this->fallback($verb, $noun);
    }

    public function fallback($verb, $noun)
    {
        if ($this->isAdmin()) return true;
        return false;
    }

    public function isAdmin()
    {
        return $this->role == self::ADMIN;
    }
}

Таким образом мы изолируем семантику ролей в одном конкретном месте, и определяем разрешения не на уровне класса Сущностей, а на уровне конкретной сущности, что гораздо гибче.

Что касается использования в view, то никаких проблем:

@if(Auth::user() && Auth::user()->can('edit', $page))
<form></form>
@endif
@if(Auth::user() && Auth::user()->can('create', 'Page'))
<a href="#">Добавить страницу</a>
@endif

Предположим, что у Вас есть комментарий, который может относится к посту(пользователя), а может относится к статье блога.
тогда у Вас таблица может выглядеть примерно так:

comment_id | parent_id | morph| comment_content | author

где:
comment_id - идентификатор самого коммента
parent_id - идентификатор сущности к которой он относится
morph - тип сущности, к которой относится этот комментарий.
comment_content, author - тут я думаю понятно
тогда записи могут выглядеть так:

comment_id | parent_id | morph   | comment_content | author
---------------------------------------------------------------
  1        |   1       | post    | бла бла бла     | vasya
---------------------------------------------------------------
  2        |   1       | article | бла бла бла     | vasya
---------------------------------------------------------------

при чем, несмтря на то, что parent_id у них одинаковый, в первом случае он относится к id в таблице post, а во втором к article
Это и называется полиморфической связью.

пример приведу на фреймворке laravel для php (но ORM там очень схож с Rails, так-что проблем возникнуть не должно)
Модель комментария будет выглядеть приблизительно так:

class Comment extends Eloquent {

 public function morph()
  {
     return $this->morphTo();
  }

}

а модели поста и статьи:

class Post extends Eloquent {

  public function photos()
  {
    return $this->morphMany('post', 'morph');
  }

}

class Article extends Eloquent {

  public function photos()
  {
    return $this->morphMany('article', 'morph');
  }

}

вроде бы ничего не напутал...

habrahabr.ru/post/79431 - читаем и осознаем примеры.

По сути это все тоже старое доброе наследование, когда у нас несколько типов записей хранятся в одной таблице и разделаются полем type. Можно в нескольких таблицах хранить и общие поля в базовую таблицу выносить... суть примерно в этом.

Фактически вам дают выделенный сервер (который просто не является железным, на то он и виртуальный). Если говорить про digitalocean - там у вас действительно всё своё выделенное (память не шарится, а аллоцируется при старте виртуалки, ядро процессора для вас личное на тарифах от $10, lvm-том с только вашей виртуалкой (фактически - выделенный для вас раздел raid-массива)).

Всеми настройками внутри системы занимаетесь вы. Более того, хостер даже не отвечает за то, что у вас система запустилась. Если виртуалка грузится до биоса - то свою работу по обеспечению работы сервера хостер выполнил (опустим в этом контексте вопросы про сеть). Если сломали ОС и она не загружается - у вас есть кнопка "переустановить чистую систему". За бэкапы, опять же, отвечаете вы (digitalocean предоставляет платные бэкапы, но они не очень удобны). За безопасность - вы.
В случае с digitalocean у вас есть доступ к "монитору" виртуалки и загрузочный rescue-livecd. В общем-то всё.

По поводу того, как настраивать (если речь про стандартный стек LAMP), то:
1) debian 7 x64
2) отключение авторизации рута по паролю, использование ssh-ключей
3) для диагностики установить snoopy, настроить логгирование sftp.
4) не использовать ftp, использовать только sftp. Желательно, по ключам. В sftp-клиенте ни в коем случае не хранить пароли от аккаунта или ssh ключа.
5) nginx+apache-mpm-itk + php 5.3 и выше + percona-server вместо mysql
6) в конфигах виртуалхостов включите open basedir, если сайт будет с этой настройкой работать (эта опция запрещает php-скриптам при обращении к ним по http выходить за пределы указанных в basedir каталогов)
7) не забудьте включить MatchUser/MatchGroup для виртуалхостов
8) обязательно настроить default host для apache и nginx, чтобы исключить неконтролируемую конфигами обработку каких либо запросов по http. Обычно вешают 403 или 404 ошибку в качестве дефолта.
9) не ставить лишний софт, не вводить бездумно команды из случайно найденных в гугле мануалов, если не понимаете что именно эта команда делает.
10) не ставить софт из исходников, особенно из недоверенных источников.
11) если на сервере нужна исходящая почта, то корректно настроить ограничения для неё. Например, для exim4 (он предпочтителен в Debian) - раз, два.
12) убрать за http-auth все лишние административные скрипты - phpmyadmin, админки сайтов, графики, мониторинг и так далее.

Это исключит почти все возможности атаки на сервер снаружи. В такой конфигурации если вас и взломают, то либо из-за украденного пароля/ключа, либо поломают сам сайт и зальют вредоносные файлы через php-скрипты непосредственно сайта.
Более того, у меня в такой конфигурации пока не сломали ни одну виртуалку целиком (были проблемы с заражением отдельных сайтов, конечно - но это было сделано явно через php), несмотря на разрешающий всё firewall и стандартный ssh-порт.

А вообще за настройку всего этого добра под 2-3 сайта админы берут около 500 рублей.

JOIN, INNER JOIN и CROSS JOIN в случае MySQL синтаксически эквивалентны.

1) Да. Не сильно зависит от размера таблицы. Время на обновление индекса примерно одинаковое на каждую запись. Данные можно читать и писать, залочена будет только текущая запись (INNODB) или будет залочена вся таблица (MYISAM) до того момента как все запишется.
2) Для индексированной строки - на запись меняется индекс.

Вставка в таблицу с индексами медленнее, чем без. Если нужно вставлять большими кусками по милиону записей и больше, можно выключить индексы, вставить данные, а потом включить.

ALTER TABLE DISABLE KEYS
INSERT INTO xxx VALUES (1,2,3)
ALTER TABLE ENABLE KEYS

В 99% это не нужно, достаточно вставлять данные большими кусками c помощью
INSERT INTO tbl_name (a,b,c) VALUES(1,2,3),(4,5,6),(7,8,9); что уже даст очень приличный прирост скорости

Многие-ко-многим реализуется через таблицу отношений. Каждая из двух таблиц сущностей имеет с таблицей отношений связь один-ко-многим. Если удалить запись из одной из таблиц сущностей, то в таблице отношений удалятся соответствующие записи связи.