Виталий Хоменко

Могу посоветовать, с чего начать.

1) кладем картинку на canvas
2) получаем при помощи getImageData() массив пикселов
3) пытаемся тыкать в него палочкой

Пункт 3 как бы самый интересный, но тут программировать надо.

Я ради фана соорудил вот такую тупую демку на CodePen, называется "Png to Html". Оттуда можно скопипастить первые два пункта и примерно понять, чо делать с третьим. Оно читает картинку из file-input, кладет на канву, затем считывает попиксельно, и для пикселов, у которых альфа-канал не равен 1 и цвет не белый (точнее avg от rgb < 250) создает DOM-узел, раскрашенный нужным цветом и спозиционированный в нужное место. И обязательно с css-анимацией! +) Так что берегите свои браузеры )))

Дальше вам надо эти пиксели как-то сгруппировать. Я бы начал с чтения статьи Connected-component labeling и гугления слов оттуда с приставкой "js". Придумаете реализацию - расскажите нам =)

А, ну и вместо канвы можно изучить png-декодеры, они бывают для браузера (если у вас только сервер - соответственно, с них и начинаем). Должно работать шустрее, но не так наглядно.

Вам поможет в этом вот эта статья https://habrahabr.ru/company/oleg-bunin/blog/321294/ Банальный Browser Fingerprint, есть и готовые решения

Используйте pm2 на продакшене
Он запустит Ваше приложение в кластере (настраивается конкретное количество процессов или по числу потоков cpu)
Будет следить за потребляемой памятью и загрузкой процессора
Сделает рестарт упавшего процесса
Будет собирать логи (console.log, console.error), с плагинами можно настроить ротацию
С плагинами можно прикрутить CI для пересборки и перезапуска проекта по webhook в git
Ну и много чего еще

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

Для чего идеальна 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" - активно развивается... Со всеми вытекающими.

Вот я думал, что в фреймворках уже ты не можешь писать паттерны-проектирования, так как ты уже пишешь в MVC-паттерне, но услышал что можно и других использовать.

Без разницы используется ли MVC или нет, это такой же паттерн как и остальные. А практически любые паттерны можно комбинировать. Поэтому использовать можно и нужно (если есть необходимость)

Так ли это и какие обычно используются?

Паттерн это готовый способ решения какой-то задачи. Соответственно какой паттерн где использовать зависит только от задачи.

1. GIT не относится не посредственно окружения для вашего кода, так что его имеет смысл использовать глобальный. А вот всякие composer / php / node / gulp / yarn /... - это часть окружения для выполнения, и их лучше держать прямо в контейнере.

Ладно там PHP со своими версиями, но эти же обычно обратносовместимы и не трубуют хранения зоопарка версий.

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

Да и PhpStorm можно один раз настроить указав путь в Git, ноде, File Watchers.

Это да.

Ведь с докером мне на каждом проекте все эти минификаторы, композеры указывать заново?

Да

Действительно ли оправдано использовать Docker одному или небольшой группой?

Да. Например хотите посмотреть проект годичной давности, но обратная совместимость зависимостей вашего проекта потеряна, такое сплошь и рядом.

Возможно, мои проекты не такого уровня, но мне действительно не критично воссоздать dev и prod окружение 1 в 1.

1 в 1 никто и не создает, а вот максимально похоже по стеку технологий - вот это правильно.

Ну и пусть там на боевом крутится php 5.6, когда у меня 7.1.

В таком окружении смысла нема. Ваш код будет работать по другому, на боевом сервере и на вирутальном окружении.

А если ты разрабатываешь с нуля и не знаешь какая будет конфигурация на боевом?

Ко боевому можно предъявлять требования.

Действительно ли деплой так прост, что заменяет все фтп-заливки, jenkins'ы, git-пуллы?

Нет

Вы полностью правы. Это - сумашествие.
Это нечитаемо, умышленно запутанно. Писать код нужно в первую очередь для других людей, которые будут код сопровождать. А компьютеру одним пробелом больше/меньше - без разницы.
Для того, чтобы в конец не сойти с ума - предлагаю вам изучить автоформатирование код в некоторых IDE. Сделал клик - и файл отформатировался под нужные вам стандарты.
Очень помогает от таких лабиринтов.
Хотя конкретно эти коды не спасет особо, тут вопрос чисто в запутанной логике коде.

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

Также для них крайне важна скорость загрузки страницы. А у адаптивного подхода очень большой оверхед в плане скачивания кучи стилей/скриптов, которые для мобильной версии не нужны.

public function render($fileName) {
    extract(get_object_vars($this));
    include $fileName;
}

это называется SSO
далее гуглите этот термин + свой ЯП.

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