Я хочу войти в привычку писать о моем прогрессе в разработке и прогрессе в моих новых проектах.

Прямо сейчас мое основное внимание было сосредоточено на новой платформе удаленного управления роботами, сосредоточенной вокруг публичных и частных групп. Вы можете думать об этом как о Slack или Discord для роботов. Название remo.tv в основном означает удаленное управление или удаленное телевидение, намекая на двусторонний интерактивный характер платформы.

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

Вы можете просмотреть текущий репозиторий здесь:
https://github.com/jillytot/remote-control

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

Мой опыт никогда не был связан с программным обеспечением, но в моей работе были времена, когда я делал довольно много. В последний раз я так много кодировал, когда делал свои собственные игры на игровом движке Unity.

Я рад продолжать публиковать о том, что я делаю, и обобщать некоторые из моих знаний.

В настоящее время я использую React.js на внешнем интерфейсе и Node.js на бэкэнде.
Я использую socket.io, так как он имеет более удобный интерфейс, чем простые веб-сокеты, однако в долгосрочной перспективе может быть более эффективным просто использовать веб-сокеты сами по себе. До этого проекта я никогда не писал API, не занимался аутентификацией, не работал с веб-сокетами или Node или чем-то еще, чем я сейчас занимаюсь. Я думаю, что самое сложное на данный момент — это иметь дело с асинхронными операциями и промисами. В видеоиграх все, что является асинхронным, обычно является преднамеренным дизайнерским решением, например, установка таймера для включения питания. Веб-разработка отличается тем, что вам приходится иметь дело со всеми, кто согласовывает свои собственные локальные версии с общей истиной.

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

message: { 
 message:    '/timeout baduser 10',
 sender:     'jill',
 sender_id:  'user-fc838f80-698f-47d3-bf52-7f987bf65d5b',
 chat_id:    'chat-81db8967-53f1-4b06-be5b-3c48a028ef53',
 server_id:  'serv-696b409f-7b23-4072-aabb-b3f6429afdac',
 id:         'mesg-91f1a1f3-be91-4e7f-b987-700d9c8b282e',
 time_stamp: 1559587067718,
 displayMessage: true,
 badges:     [ 'staff' ],
 type:       '' 
}

Это запускает событие тайм-аута непосредственно на сервере.
Однако я хочу, чтобы команды чата были заменой для графического интерфейса модерации, поэтому тайм-ауты должны обрабатываться через отдельные события сокета, испускаемые клиентом или даже API.

Я буду немного реструктурировать вещи с этой целью, прежде чем строить слишком много поверх этого.