D'

смысл затеи в чем?

примерно так:
ssh -D 8888 user@host -p 22 -i ~/.ssh/my-key
затем в сетевых настройках системы/приложения/браузера указываете:
proxy:
host - 127.0.0.1
port - 8888
type - SOCKS5
и весь трафик пойдет через ваш ssh.

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

Проверьте сначала, для Вас ли заблочен сайт или для всех. Попробуйте сделать это на одном из сайтов:
downforeveryoneorjustme.com
cameleo.ru

Затем стоит проверить систему различными сканерами руткитов и антивирусами:
chkrootkit
rootcheck
rkhunter
clamav

посмотреть открытые порты в системе, есть ли они:
netstat -anltp | grep "LISTEN"

Еще я как-то писал свой баш скриптик, который позволяет делать мониторинг уровня б, следить за портами, новыми юзерами, новыми пакетами:
https://github.com/ADMINICANA/ubuntu-server-daily-...

Хорошо бы просто посмотреть трафик, сделав tcpdump, какая активность идет, если ее быть не должно - насторожиться. Посмотреть разные логи, history юзеров.

Правый вариант хоть как-то воспринимается, т.к. влазит на один экран. Левый - стена непонятного повторяющегося текста, будто EULA в очередной раз подвернулась.

Неплохо бы переписать всё так, чтобы не было этих одинаковых повторяющихся кусков. Мало кому интересно читать высокохудожественный текст о доставке мебели. Целесообразно выделить ключевые моменты - цена, стоимость и сроки. А повторять три раза предложение "стоимость вы можете уточнить..." - это перебор, имхо.

Нету стандартных средств. Есть сторонние пакеты:
https://github.com/VentureCraft/revisionable
https://github.com/jarektkaczyk/revisionable

чтоб что-то получить из куки надо сначала что-то туда сохранить.
если кратко - нельзя.

ssh, vnc, teamviewer.

Вот вам 12 маленьких задач на 12 паттернов:
github.com/zfcampus/zendcon-design-patterns

1. Открываете папку с паттерном.
2. Читаете README.md с описание задачи.
3. Открываете exercise.php и пытаетесь решить задачу, применив соответствующий паттерн.
4. При необходимости вспоминаете теорию: github.com/domnikl/DesignPatternsPHP
5. Сверяетесь с решением в solution.php.

жеванный крот!

долго объяснять, лучше станцую:

$directory = 'images/';

$files = glob($directory . '*');
$sql = '';
foreach ($files as $file) {
	if(is_dir($file)) {
		continue;
	}
	$sql .= '("' . $file . '", 3),';
}

$sql = 'INSERT INTO `people`(`name`, `deptId`) VALUES ' . substr($sql, 0, -1);
echo $sql;

надеюсь смысл понятен.

Очевидно, что это комбинация для быстрого перехода к строке поиска.
А вопросительный знак нужен, чтобы при поиске чего-то, что похоже на домен (например, VB.NET) искалось это слово, а не происходил переход на домен. Своего рода экранирование поискового запроса.

Подробнее

php.net/manual/en/class.recursiveiteratoriterator.php и тогда один форич.

либо рекурсивная функция на основе array_search.

BigData не очень то и связана со структурами данных - в основном это разнообразные пространственные структуры, скорее больше связана с алгоритмами NLP, классификации и машинного обучения.

В первую очередь нужно выбрать средство обработки и хранения.
В случае с Java это HBase Cassandra
HBase - когда пишется в базу очень много, и большинство индексов "самодельные".
Cassandra - когда соотношение чтения / записи 4:3, так как в Cassandra уже есть средства колоночной индексации.

В случае с реальным высоконагрузом это ScyllaDB - обладает теми же особенностями что и HBase, но С++11 и Share-nothing approach и от того в 6-7 раз шустрее.

Для БД до 200Гб хватит банального MySQL'я c R-tree индексом и Engine Archive.
Вот PostgreSQL при правильной настройке спокойно строит B-tree индексы для объёмов данных в 500-700Гб, что для MySQL'я непосильная задача Ну и в PostgreSQL часто приходится дописывать сишные функции агрегации и строить по ним разнообразные индексы, иногда пространственные (gin/gist).

Вот небольшой обзор разных типов индексов.

От себя ещё добавлю MVP-tree для поиска похожих персептивных хэшей и Fusion-tree как более съедобный вариант дерева Ван Емде Боаса.

По поводу хипстер-культа вокруг MongoDB - скажу что PostgreSQL с индексами на хэш-таблицах и небольшими множествами документов в 1.5-3 раза шустрее, потому что "Building Index with Vodka". А нормальная репликация и партицирование напрямую зависит от принципов решения задачи Консенсуса в каждом конкретном приложении, и без понимания работы Raft / Paxos не стоит надеятся на чудеса той же MongoDB или PostgreSQL, они являются не более чем инструментами для решения этой задачи.

MongoDB очень даже ничего для реактивных проектов на основе Meteor, а для всего остального уже GoldenHammer™.

По индексации, надо обязательно-обязательно прочитать книги Ханны Самет
Foundations of Multidimensional and Metric Data St... = Applications of Spatial Data Structures: Computer ... + The Design and Analysis of Spatial Data Structures

В принципе книжки Foundations of Multidimensional and Metric Structures должно хватить с головой, но можно "дочитывать" более полное описание в более древних работах. Одним словом тётка "жжёт", и я не знаю почему это до сих пор никто не перевёл.

Ну после того как разобрались что и где и как хранить, теперь можно думать по поводу обработки...
Есть древняя книжка "Алгоритмы интеллектуального Интернета" и "Программируем коллективный разум" Хоть названия переведены на русский довольно странно и звучат довольно наивно - это хорошее введение в простые средства обработки и анализа данных.

По машинному обучению можно пройти курс Эндрю Ына на курсере.

Есть Южный DataScience-централ, там есть много чего полезного. Его можно почитывать. Есть ещё поверхностные CheetSheet'ы, видел и получше, но не нашёл.

Как DeepLearning адепт советую разобраться с Theano, и методами описанными тут. В продакшенах эта штука до безобразия слоупочна и видел товарищей которые более-менее успешно слезли на Neon.

Если лезть в Java, то на примере Spotify чаще всего используются связки
Apache Kafka -> Apache HBase -> Apache Storm -> Apache Spark (mllib) -> Apache HBase -> Apache Phoenix -> Hibernate + любой MVC фреймворк и т.п.

Естественно об относительно высокой производительности и хорошем вертикальном масштабировании речи не идёт, если брать C++11 ScyllaDB -> Neon хорошо отпрофилировать и допилить, можно получить в 3-5 раз выше производительность и соответственно гораздо меньшие задержки, но обычно всем влом. REST API под такое обычно пытаются писать на сях (без плюсов) в виде расширений под Nginx, что является довольно породистым извратом - в большинстве случаев банального golang/netty будет достаточно.

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

По поводу HA и Zookeeper можно увидеть много срача, особенно в Netflix'e, по этому для менеджмента высокой доступности лучше использовать именно их решения - eureka или для отказоустойчивости Hystrix. Хотя я не могу сказать что это достаточно зрелые проекты - в них тоже хватает изъянов, но они на много шустрее остальных Apache поделок.

Нельзя делать одновременно отказоустойчивые и высокодоступные приложения - потому что CAP теорема имеет место быть.

Ещё есть очень тонкий момент с Java в целом - нужно минимизировать время сборки мусора и лезть в offheap, стоит глянуть как реализованы буферы в netty - это arena аллокатор по типу того что используется jemalloc и различная misc.unsafe ересь. Можно ещё пробовать Hazelcast / Terracotta, но принципиально там тоже самое, только платно и "расспределённо".

Для REST API я чаще всего использую Vert.x и ванильную Java.
Overhead от Scala довольно таки большой, а время компиляции просто вырвиглазное.
Для минимизации копи-пасты вполне безопасно использовать Groovy c @ Immutable и @ CompileStatic.
Но в Vert.x'e он весь "динамичный" :|

Я ничего не могу сказать по поводу производительности Clojure, он местами через чур invokeDynamic. Естественно что ванильная Java будет шустрее, но я без понятия на сколько.

Желаю Вам приятного вечера.

p.s. не везде проставил ссылки просто потому что хочу спать.

ответ - не пихать ангуляровские темплейты в blade, если вам надо каким-то образом передавать данные - то самый простой способ делать это так:

angular.module('app.prefetchedData', []).constant('prefetchedData', {
    // some serialized data from laravel
});

все остальное - вынести в отдельные файлики или бандлить штуками типа webpack.

Еще относительно правильный способ - экранирование (в blade же есть raw или что-то подобное как в twig?)

Ну и третий вариант, сродни кастылю и вам должно быть слегка стыдно за его использование - в $compileProvider есть возможность установить как именно обозначается биндинг значений в angular.

Angular 1.5 задумывался авторами как переходная точка, что бы проще мигрировать людей с первого на второй. Так что учите angular 1.x и соблюдайте стайл гайд. Ну и почитайте про MVC, про компонентный подход к разработке на Angularjs. (отказ от двустороннего датабиндинга, данные должны идти только в одном направлении, упор на классическую схему MVC).

Нормальная форма

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

fontello.com - можно сделать свой набор иконок из fontawesome и еще почти десятка наборов, плюс добавить свои svg.
Но если нужен только гамбургер, имхо, вообще не нужно внешние файлы подключать, сделайте на CSS или инлайновым SVG.