Philipp

Когда-то я писал на PHP. Писал много. Сначала это было месиво из кода на PHP и HTML, потом появились всякие шаблонизаторы, стало чуть чище.
Проекты росли, кода становилось все больше и хотелось некоторые кусочки переиспользовать. Так я пришел к управлению кодом через Composer.
На каком-то этапе разработки я столкнулся с тем, что у меня было 2 разных веб-интерфейса делающих одно и то же. Вдобавок нужно было часть данных отдавать в систему логистики. Причем это должно было быть автоматизировано. Тогда я уже знал, что есть такая штука - автоматизированные программные интерфейсы (API).
Наскоро было что-то написано и оно заработало. По итогу, оба веб-интерфейса и система логистики использовали одни и теже функции. Но поддерживать 2 разных интерфейса было очень геморно. В те времены был jQuery самым главным. Очень сложно было добиться правильного отображения, посколько Javascript код был в перемешку с HTML, часть которого генерировалась из PHP. Возникали ошибки. Данных было много, разных скриптов было много (сотни), части скриптов были копиями друг друга с небольшими отклонениями. По итогу, на решение простых задач вроде редактирования строчки в таблице с обновлением на сервере уходило много времени, дни, иногда даже недели.
Потом я увидел Mustache.js, это был предок Ангуляра и Реакта. Что-то вроде шаблонизатора, но только на стороне клиента. Работало оно только в одну сторону, отображало данные в HTML, но потом была та же жесть из jQuery.
Затем я познакомился с Angular1. Идея была простая - пишешь шаблон, подставляешь в него данных. Оно отображается, само! Никаких тебе извращений, найди класс или идентификатор, или еще какая-нибудь ерунда.
Кодить стало проще. Стало можно создавать библиотеки компонентов и просто редактировать стили. Можно было сделать компонент для ввода и проверки почты, и использовать его сразу во всех проектах и исправлять ошибки в одном месте, а не бегать по сотням скриптов и искать в каждом этот повторяющийся косяк.
Поначалу я тоже относился к Ангуляру с предубеждением, столько траблов, стоят ли они того. Но как только я стал чаще сталкиваться с задачами, когда мне понадобились разные интерфейсы для отображения одних и тех же данных, это стало сходить на нет.
Пока вы пилите простые штуки, всякие фреймворки вам не втарахтели. Даже jQuery не нужен. Но иногда начинается жопа, когда одному уже проект не вытащить, ибо охеренеть, как сложно, а еще и делать надо быстро. Поэтому лучше разделиться, кто-то делает бэкенд, кто-то фронт. Так просто удобнее, а общаться через API. Вначале вы вместе просто пишите спецификацию для API, это занимает день или два. А потом вы бомбите месяц в параллель. Причем фишка такого подхода в том, что есть инструменты, которые просто выдают заглушки для кода на фронте. Т.е. если фронт пишется быстрее, то его проще тестить и все такое. Аналогично с бэкендом. Его тоже можно тестить даже если фронт не готов. Причем эти все фишки особенно круты, когда вас не двое, а например 20, да и живете вы по всему миру в разных часовых поясах и т.д.

Если у вас форма уходит на почту, зачем там номер телефона?
Разве не логично спросить эл. почту?

Я думаю, что вы еще не совсем созрели для IT-Архитектора.
У профи данного уровня такие вопросы не возникают.

Итак, учим матчасть:

• anycast
  
• wild-card certificate
  
• REST
  

Вам не нужно иметь миллион разных доменов и десяток сертфикатов.
Решение - нормальный балансировщик.

А в остальном, лучше всего сделать что-то в стиле:

GET https://f.s.com/path/to/file.ext скачать
POST  https://f.s.com/path/to/file.ext закачать
PUT  https://f.s.com/path/to/file.ext заменить
DELETE  https://f.s.com/path/to/file.ext удалить

На s.com можно лендинг/приложеньку повесить.

А в целом, прочитайте про NIH и начните использовать Ceph.

99% этих сайтов имеют 2 проблемы - описание вакансий полное дерьмо и опыт подачи на работу практически не отслеживается.

Вот, нагуглил вам https://www.pcbquick.com/pid18120925/4-Layer-PCB-C...

Никак.

Информация размещенная на страницах соц.сетей принадлежит человеку, а не вам.
Существует понятие свободы слова. Если до сих пор оно вам не знакомо, то советую ознакомиться. Человек вправе указывать о себе любую информацию.

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

Если человек недобросовестно использует имя компании и т.д., то идите к юристу. Этот вопрос следует решать в правовом поле. Хотя я рекомендовал бы передупредить об этом.

Бывают ситуации, когда инфа стоит необновленная годами. Человек либо не заходит в соц.сеть, либо ему просто наплевать на информацию.

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

Даже увольнять следует с уважением. Особенно в такое тяжелое время.

Для того, чтобы создать простой веб-сайт, вам не нужен PHP.
Возьмите старый добрый HTML и сделайте 2-3 странички в редакторе. Готово.

https://github.com/prometheus/client_python

На Youtube много всякого, например:
https://www.youtube.com/channel/UCrRiVfHqBIIvSgKmg...
https://www.youtube.com/user/rachelsenglish
https://www.youtube.com/channel/UCz4tgANd4yy8Oe0iX...

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

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

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

Я так понимаю, никаких здоровых процессов по развертывания проекта у вас нет. Советую присмотреться к какой-нибудь CI, даже тот же Deployer облегчит вашу жизнь. Он прекрасно работает в связке с Laravel.

У меня впечатление того, что вы не совсем понимаете, что такое NPM и Node.js.

Для начала нужно разобраться с понятиями клиента и сервера. Клиент - это браузер, сервер - то, откуда клиент получает ресурсы. Ресурсы - это html, css, js (созданный для выполнения на клиенте).

Node.js - это реализация движка Javascript (того самого, который в бразуере), но с применением его на стороне сервера.

Javascript - это просто язык программирования, но код, написанный на нем, может выполняться в разных средах, т.е. на стороне сервера (node) или на стороне клиента (браузер). Этот код очень похож, но имеет некоторые отличия.

npm - это пакетный менеджер, упрощенно его задача скачивать архив с кодом и распаковывать в node_modules.

Когда вы запускаете app.js, то вы запускаете процесс Node, который интерпретирует файл app.js и выполняет инструкции написанные в нем. В вашем случае эти инструкции говорят - запусти сервер и начни слушать порт 80, отдай нужный контент по запросу. Т.е. app.js файл написан для того, чтобы быть интерпретирован движком Node, а не движком браузера.
Когда вы подключаете app.js внутрь страницы, то движок браузера не понимает, что делать с этим файлом, т.к. в нем отсутствует поддержка серверного движка. Поэтому вы и видите ошибку.

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

npm - отличный инструмент для быстрой установки зависимостей, библиотек и т.д. Но им нужно научиться пользоваться. Есть еще nvm - управление версиями Node.js, тоже надо.

Дам вам совет - посмотрите https://learn.javascript.ru/screencast/nodejs и разберитесь, что и в каком контексте выполняется. Там же вы найдете пояснения по поводу npm.
Советую пройти https://ru.hexlet.io/courses/js-setup-environment (это бесплатно).
И это под конец https://learn.javascript.ru/screencast/webpack

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

3. При заказе на моем сайте будет автоматически идти заказ в другом магазине

Так делать не стоит с юридической точки зрения. Вам нужно указывать посредника.
С технической точки зрения система автоматизации заказа реализуется через API магазина посредника. В данном случае вы несете ответственность за обработку и хранение данных пользователей со всеми вытекающими.
Это сложно, долго и дорого. Готовы? Если нет, то промо-код и реферальные ссылки для вас самое то.

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

class LoggerFactory {
  static $instance = null;
  public static create() {
    if (!is_null(static::$instance)) {
      return static::$instance;
    }
     static::$instance = new Logger('name');
     // ну т.д.
     return static::$instance;  
 }
}

// используется вроде бы так
$logger = LoggerFactory::create();

Код я не проверял, но идея примерно такая.