Looking for developers to help with the chat client


#1

Hello amazing community!

We’re in search of developers willing to help build the front end of the TMRO chat client. We have Colten as always leading the charge here, but I really want to lighten his load and allow him to focus on the next generation of new, cool and amazing features.

We’re working on porting the client over to AWS CodeShare and hoping some people can pop in, take a peek around and help look for any bugs, improvements or just all around suggestions on what we can do.

Hoping to build a small team of regulars to enhance our chat experience and make it freaking awesome. This is the life blood of the shows and you’ll have a direct hand in helping create the future of TMRO.

Thoughts?

-B


Asking for coders?
#5

I’ll just put my name here so I get a notification when links are available.


#7

#8

I will of course be happy to help … am now home just waiting for my health to settle a little and will poilish off the auto name slide projetc.


#9

Hey Scott, hope I can call you Scott. Please let me know if you are on Discord and what your username is. I will get you into the dev channel and can get your email etc. We can talk much more there and will soon be creating IAM credentials on our AWS account for each person who wants to work on the TMROChatClient git repo that I will soon be throwing up basic templates of the page as well as a base of the networking code for it to connect to the server and handle the protocol. It’s all IRC but since the web client uses websockets I started out with socketio and the event “raw” to pass a regular irc formatted string through. This will end up changing once I catch up on the latest changes in the newest versions of socket io since it allows hooking into the actual raw stream of data before the socketio event parser that sends JSON objects between the connections.

I’ve already done the parsing of the irc protocol and have made it easy so all you have to do is go and create functions CommandName(data,app,socket) data is an object of the parsed string with a structure of {data:‘the raw string’,tags:‘ircv3 tags string not parsed’,from:‘user host/servername’,event:‘event name ie PRIVMSG’,eventparams:‘parameters for the event/command ie for PRIVMSG either #channel or username’,msg:‘the message’}

Not quite BNF but close the formatting of the ircv3 packets would be
[@tags] [:from] <event> <parameters> [:message] CRLF
Where as ircv2 would be
[:from] <event> <parameters> [:message] CRLF

Usually event is called “command” when talking about irc but for some reason I have changed to event and have just stuck with it. “From” also is usually referred to as the prefix and can actually be many things not just who or what the “event” is “from” but for the most part it usually indicates a name for where the event came from, be it a server or a user. Tags right now will be hosting timestamps,msg ids and will end up having urls for “avatar” images and other information mostly dealing with hosts like what the either RGBA or hex value is for the host specific colored buttons that they will set/request from the server. A tag will be formatted as tagname1=tagdata;tagname2=data prefixed by @ in the raw data stream. But there will be a function parseTags(rawtagstring) that will be called within the command functions as to reduce the amount of code being called for each packet since not all commands/events will have tags and even when they do, sometimes it wont need to be used depending on ui settings the user has chosen. But the parseTags function will return an object with {tagname1:‘tagdata’,tagname2:‘tagdata’}

So for the most part. The heavy lifting will be done for you. The major thing is getting the current angular and material template and components to a state that matches the current web client. And if you want to go ahead and start looking through documentation of what I would like everything to be in. https://material.angular.io/ but if everybody decides hey lets just work with just typescript and something like material lite or even if you want to go hard core and write your own html5 web components based on material design or any other design spec that Ben signs off on, then I am all for that. But I think angular and the angular material would allow faster development and get things off to a good start and with a semi regular pattern for everybody to adhere to.

and with that massive wall and it being super late. I am going to sign off for now. Please DM me on Discord I am “Colten45” and you can also reach me at colten@tmro.tv

I can not wait to work with you all to make the future of live communication interaction software for live broadcasts! We will be making the best option out there for any live broadcast to bring a level of live interactions between hosts and viewers that hasn’t been done elsewhere! So lets do our best to make sure the experience is the best we can possibly make and allow viewers a chance to interact with the people they love and watch on any platform they so choose and get near instant feedback from their favorite shows in real time! This is the future, this is TMRO!


#10

…“other design spec that Ben signs off on”

In one of my previous lives, I helped create requirements for things like this, so some additional thoughts came to my mind:

-Since TMRO has a global footprint, the app/widget/environment must be GDPR-compliant.
-Must be OS-neutral.
-Must be browser-neutral.
-Strive to be device-neutral.
-Strive to provide the main UI menus in multiple, user-selectable languages.
-Must be able to leap tall buildings… No wait; that’s a requirement for something else.


#11

@Freda that’s really great advise. Actually, coming up with a roadmap and release timelines / systems / code checks, etc would also be very valuable. Would you be able/willing to help with some of those things?


#12

I think I just decided on a new catchphrase! Thanks Colt!


#13

Hmmm… possibly. I’m not smart enough to open the hood and work on the engine, but I might be able to help draw a map to drive the car. I’ve learned that success is easier when you start with some level of “business requirements” document that weighs enough to be the key reusable foundation during development, system testing, acceptance testing, documentation, and even production support. Children of that initial doc would be a Functional spec (expected features), Technical spec (describing tech details), Test Plan (that connects back to all Parent items) and any Change Mgt and communication plans. I now find myself challenged by typing on a very small device screen and worry that I haven’t done a good job, so I will pause.


#14

I would say it is more drawing an outline of what the car itself will become, which can be just as important if not more so than the actual building of said car!


#15

This is for sure what we’re aiming for right now! And between the features we need and the very poor details I have written on a regular notepad. There may be use of someone to help sift through current and new features and properly format documentations and specifications that everyone can understand and follow.


#16

@Freda I agree with Ben, this is more important than actually building anything, without a solid understanding and overall view of a project. It would be hard and would take longer to think of things as they go. Like if a car was made but a simple forgotten bolt and engine mount could turn an idea of a car quickly to massage chair on wheels.

We would highly love if you could help tidy the horrible todo list of mine and maybe to help create those Functional specs so we can be sure we create a good timeline and weighted issues to complete. Technical spec, it would be nice to have so we can give to any new developer that would like to join so they can either do their homework or dive right into an issue that they know the technical details of already.

We for sure will need some plans and guidelines for us all to use and follow in nearly every aspect of development, testing and maybe how to handle regular user reported issues and bugs.

As this will be my first time really controlling a team that could easily grow larger than I may think we will get to any time soon. I for sure want to make sure I can easily communicate to the entire team and make sure we’re all on the same page.

Now, you wont have to go and think of everything or get all the data on your own. I have much of that and can explain it all (not very good, I am a developer more than a visionary I would be the Woz to any Jobs). So to have someone who can order and organize my very horrible and always changing thoughts would be very nice.


#17

angular + material … :+1:
gimme git :slight_smile:


#18

We are on gitlab! If you would like to help out in anyway, let us know what areas you would be interested in and we will slide you in somewhere!


#19

Hi
I am a longtime webdev and can help with frontend stuff, code review etc.
If you need angular(material) components, or just a tester/reviewer let me know


#20

@Bencredible and @Colten45, great! :+1: Let me grab a reference from previous good deployments and reply back… maybe 1 or 2 days. Thank you, Freda


#21

That will be great! I will make sure I try to digitize as much as my physical notepad as I can and get it semi understandable and will give it a home very soon so it can be ripped apart and pieced back together in a better way.


#22

That is awesome and we do need someone who has worked with angular and material previously. I know enough to get around. So, your skills will be highly appreciated! And why we put out this request looking for people to work on the user side of the TMRO chat.

We highly need the new client up to par with everything that is needed for all the new features of the Beta server. It is holding me back on more than just a few things and with your help as well as others. I can really focus on making the back end and push out fully functional and stable updates out at a faster pace than what I was doing when dealing with the “full stack” alone.

Networking and servers are my area and with the help of the community; I can get the features both needed and wanted away from an old and very long “todo” list that has become filled with “feature creep” top to bottom. So that they actually become features and not just words on a piece of paper.

On that note, I will have some snippets of networking code up on gitlab by tomorrow night. And will have some angular/material test pages I have done mostly just to get an idea of the main client interface. I hate to admit, it took me longer than I like to get material to do things it may have not been perfect at doing. Like putting horizontally scrollable navigation tabs into the header/ (navbar/slide out ‘no scrolling here just vertical list’) while keeping the hamburger menu and user list tab in the mix. Though, If any suggestions to make this more user friendly would be greatly considered if it’s right. I was just wanting to somewhat keep with how the “old” regular chat client looked and functioned so that a crazy change wouldn’t distract users from being able to use it.


#23

@Colten45 Rather than post a too-detailed document here, I would like to send something directly to you and @Bencredible What is the best way to do that? I tried using a PM in this forum, but can’t attach a doc.

And… if you send me any to-do lists you have, I can bring them into the framework doc I will send, More later…


#24

You could try a link to a google doc perhaps? The shared editing feature could eventually prove useful in a group collaboration.