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

1. Работа над личным брендом: Высокая репутация в профессиональных сообществах повышает привлекательность для нанимателей.
   
2. Улучшение существующих знаний: Хочешь что-то понять, объясни другому.
   
3. Приобретение новых знаний: Специализация замыкает в узком спектре задач и проблем, а Q&A-сервисы - это источник задач и проблем из самых разных областей и иногда под самыми неожиданными углами.
   
4. Альтруизм: Большинству из нас кто-то помогал в начале пути, пришло время возвращать долг и делать свой скромный вклад в рост кадров.
   

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

Для чего просиживаете на тостере по 5-6 часов в день?

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

https://symfony.com/doc/current/service_container/...

services:
    _defaults:
        autowire: true
        autoconfigure: true
        bind:
            App\Repository\Repository $cachedRepository: '@App\Repository\User\CachedUserRepository'

    App\Repository\Repository: '@App\Repository\User\DoctrineUserRepository'
    App\Entity\UniqueEntityInterface: '@App\Entity\User'

    user_exists_checker:
        class: App\ExistsChecker
        bind:
            App\Repository\Repository: '@App\Repository\User\ApiUserRepository'

Может пригодится, если несколько реализаций интерфейсов: https://symfony.com/blog/new-in-symfony-3-4-local-...

Чтобы переопределить реализацию интерфейса для конкретного сервиса

user_exists_checker:
    class: App\ExistsChecker
    bind:
        App\Repository\Repository: '@App\Repository\User\ApiUserRepository'

Можно переопределить интерфейс для определенного названия переменной https://symfony.com/blog/new-in-symfony-4-2-autowi...

_defaults:
        autowire: true
        autoconfigure: true
        bind:
            App\Repository\Repository $cachedRepository: '@App\Repository\User\CachedUserRepository'

В примере выше, если в конструкторе вместо App\Repository\Repository $repository будете использовать App\Repository\Repository $cachedRepository, то вам придет App\Repository\User\CachedUserRepository

https://www.elastic.co/elk-stack

Потому что вы передаёте им разные строки.
Уберите -n и результат станет одинаковый.

$ echo 'hello' | openssl base64 
aGVsbG8K
$ base64 <<< 'hello'
aGVsbG8K

$ echo 'hello' | base64
aGVsbG8K

Прочитать соответствующий RFC https://tools.ietf.org/html/rfc6455 чтобы понять, как происходит рукопожатие и какие байты в переданном сообщении за что отвечают. После этого будет понятно как написать реализацию. Я досконально уже не помню, но фактически от клиента приходит обычный http запрос с определенными заголовками, сервер разбирает этот запрос и если всё ок, то сохраняет открытое соединение в массив, если нет, то отправляет соответствующий ответ и закрывает соединение. Дальше по открытому соединению начинает сыпаться поток байтов от клиента их нужно разбирать, чтобы понять длину сообщения, сами данные переданные в фрейме, закончился фрейм или еще нет и тому подобное. Обратно также кодировать данные в поток байтов и отправлять по открытому соединению. Каждый байт в переданном фрейме несет определенный смысл. Обо всем этом подробно написано в RFC, но на английском. Вообще это хорошо примерно понимать как работает, но глупо писать такую низкоуровневую реализацию, когда есть готовые. Такие вещи развивают и поддерживают годами. Вы же не пишите HTTP серверы, а берете готовые вроде nginx и тому подобное.

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

Как сделать, что бы на стороне клиента, один websocket отвечал за сообщения, другой за статьи. (Или за эти два действия отвечает один websocket, тогда как мне на сервере это различать).

Вебсокет это низкоуровневая штука, для передачи потока байтов от клиента на сервер, в отличии например от HTTP, где есть заголовки и тело сообщения. Поверх вебсокета нужно делать еще один протокол или самописный или выбрать один из готовых. Это проще говоря, то как выглядят ваши фреймы (сообщения), которые вы отправляете с клиента на сервер и назад. Например клиент может отправлять такой фрейм:

["id", "controller/action", {param1: value1, param2: value2}]

в ответ получать
["id", "OK"]
если запрос был обработан успешно или
["id", "ERR", {error: "action not found"}]
если произошла ошибка. По переданному id в массиве, можно понимать, к какому запросу относится ответ.
Для уведомлений (событий) сервер может отправлять клиентам что-то такое
["user_added", {user: {...}}]
и т.д. Этот протокол необходимо придумать самому или выбрать из готовых (популярных пока нет) и написать его реализацию (клиентскую и серверную часть) или опять же взять уже готовую.

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

Но это уже всё должно быть, просто возьми real-time фреймворк. Там за тебя написали и websocket сервер и протокол поверх него и экшены уже есть. Всё низкоуровневое уже готово. Бери и пиши приложение. В nodejs самый популярный это например https://github.com/socketio/socket.io, а в php я не знаю, но уверен, что тоже есть что-то популярное.

Своё написать не получится, без опыта и без попыток сделать приложение на чем-то готовом. Нужно как минимум прочитать RFC и посмотреть реализации других разработчиков. Для этого нужно быть кем-то больше, чем "программистом сайтов".

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

У софта, библиотек, и прочих зависимостей бывают версии. Еще и у железа отличия бывают.

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

Собрав у себя локально и перелив на сервер, у которого отличается окружение - рискуете получить кучу глюков, и чем больше оно отличается, тем сильнее рискуете.

Дело вкуса. Я знаю JS, но совершенно не хочу вкатываться в nodejs. Зачем мне нода, когда и php решает те же проблемы?

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

Боязнь изучения другого языка в вашем случае не оправдана. Попробуйте Python/Java/PHP. Ознакомитесь где вот вам проще искать документацию, приятность синтаксиса, скорость разработки. Где вы решаете проблему из мира живого, а не из мира "Как эта штука работает".

Я как-то хотел изучить Haskell, долго блуждал, но в итоге сложилось ощущение, что язык решает проблему для себя, а не для меня. Мне банально было неудобно всё в том языке. Даже родной редактор завершался с критической ошибкой...

Если Вам нужен хороший UI для пользователя, то однозначно нужно смотреть в сторону Linux Mint - он прост в освоении интерфейса. Люди которые привыкли работать на Windows легко смогут понять и перейти на Mint.
А что бы организовать организовать централизованное управление, Вам лучше Ansible - там начиная от автоматическую установку программ и заканчивая настройкой файлов конфигураций.
По поводу периферии и прочих, то лучше мяты никто не работает. Там все эти проприетарные кодеки, фирмвари и прочее.
Так что Вам нужна мята желательно с корицей - однозначно !!! (Linux Mint 19 "Tara" - Cinnamon)
Напишите пару плэйбуков на Ansible и быстро развернете что вам нужно.

Ansible
Linux Mint 19 Tara Cinnamon

Если кратко, то существуют 4 вида NAT-а, которые нужно как-то преодолевать, 3 из них лекго преодолеваются при помощи STUN-серверов (они используются только в момент соединения пиров друг с другом - то-есть весь трафик через них не идет, есть куча бесплатных stun-серверов), четвертый - самый проблемный, под него подпадают примерно 15% всех peer-to-peer соеднинений в Интернете - это так называемый двойной NAT (когда оба пира скрыты за NAT-ом). Для преодоления этого четвертого вида NAT-а нужен TURN-сервер. Его особенность в том, что он работает как прокси - то-есть пропускает весь трафик через себя - отсюда вы должны понять, что бесплатных TURN-серверов вы не найдете. Те аккаунты, что вы привели сверху скорее всего уже давно отключены.

Отличный список STUN-серверов можно взять здесь - https://github.com/DamonOehlman/freeice он там постоянно проверяется и обновляется.

Проблемя с двойным NAT-ом решается одним из трех способов:
1. где-то находите временно халявный аккаунт на TURN-сервер (но аккаунт внезапно могут отключить)
2. покупаете платный аккаунт на уже существующем сервере и платите за трафик, например здесь - https://my.xirsys.com/signup/plans/standard/monthly
3. Разворачиваете свой turn-сервер. Мы, например, так и сделали. Взяли убунту за $5 в месяц на digitalocean и поставили там за пол дня опенсурсный, бесплатный turn-server - turnserver.open-sys.org/downloads