Zoom

We use Zoom for external meetings with clients and Slack is used when meeting internally as a team.

I own an Escape Room. Since right now everyone is practicing social distancing, I would like to run my Escape Room games virtually. I would like to allow approx 4 users to log in to play. They can chitchat a few minutes before their game to get to know each other. Then once the game begins, I will introduce myself and give them the plot to their escape game. I will have a wide-angle camera mounted to the wall to show the room, and as the game master, carry a tablet or webcam around as players talk to me and direct me to show them certain items in the room, move in for closeups in certain areas, try lock combinations, etc. I will be their hands while they solve the puzzles. I am not sure if Google Hangouts Google Meet or Zoom is better for this. I did try it yesterday using google hangout meet and it was good, but I think there may have been a wifi issue where it was choppy. Just trying to figure out the best option. Thank you! Catherine

Hi, I am building an enhanced web-conferencing app that will have a voice/video call, live chats, live notifications, live discussions, screen sharing, etc features. Ref: Zoom.

I need advise finalizing the tech stack for this app. I am considering below tech stack:

• Frontend: React
• Backend: Node.js
• Database: MongoDB
• IAAS: #AWS
• Containers & Orchestration: Docker / Kubernetes
• DevOps: GitLab, Terraform
• Brokers: Redis / RabbitMQ

I need advice at the platform level as to what could be considered to support concurrent video streaming seamlessly.

Also, please suggest what could be a better tech stack for my app?

#SAAS #VideoConferencing #WebAndVideoConferencing #zoom #stack

Hi! I am trying to decide between using Calendly or Meetingbird for my consultancy. I would like to connect 3/4 calendars (via Gmail / G Suite) and primarily use Zoom as my connection platform. I'd love to hear about what others use and your recommendations/points to consider. TIA!

Server side

We decided to use Python for our backend because it is one of the industry standard languages for data analysis and machine learning. It also has a lot of support due to its large user base.

• Web Server: We chose Flask because we want to keep our machine learning / data analysis and the web server in the same language. Flask is easy to use and we all have experience with it. Postman will be used for creating and testing APIs due to its convenience.

• Machine Learning: We decided to go with PyTorch for machine learning since it is one of the most popular libraries. It is also known to have an easier learning curve than other popular libraries such as Tensorflow. This is important because our team lacks ML experience and learning the tool as fast as possible would increase productivity.

• Data Analysis: Some common Python libraries will be used to analyze our data. These include NumPy, Pandas , and matplotlib. These tools combined will help us learn the properties and characteristics of our data. Jupyter notebook will be used to help organize the data analysis process, and improve the code readability.

Client side

• UI: We decided to use React for the UI because it helps organize the data and variables of the application into components, making it very convenient to maintain our dashboard. Since React is one of the most popular front end frameworks right now, there will be a lot of support for it as well as a lot of potential new hires that are familiar with the framework. CSS 3 and HTML5 will be used for the basic styling and structure of the web app, as they are the most widely used front end languages.

• State Management: We decided to use Redux to manage the state of the application since it works naturally to React. Our team also already has experience working with Redux which gave it a slight edge over the other state management libraries.

• Data Visualization: We decided to use the React-based library Victory to visualize the data. They have very user friendly documentation on their official website which we find easy to learn from.

Cache

• Caching: We decided between Redis and memcached because they are two of the most popular open-source cache engines. We ultimately decided to use Redis to improve our web app performance mainly due to the extra functionalities it provides such as fine-tuning cache contents and durability.

Database

• Database: We decided to use a NoSQL database over a relational database because of its flexibility from not having a predefined schema. The user behavior analytics has to be flexible since the data we plan to store may change frequently. We decided on MongoDB because it is lightweight and we can easily host the database with MongoDB Atlas . Everyone on our team also has experience working with MongoDB.

Infrastructure

• Deployment: We decided to use Heroku over AWS, Azure, Google Cloud because it is free. Although there are advantages to the other cloud services, Heroku makes the most sense to our team because our primary goal is to build an MVP.

Other Tools

• Communication Slack will be used as the primary source of communication. It provides all the features needed for basic discussions. In terms of more interactive meetings, Zoom will be used for its video calls and screen sharing capabilities.

• Source Control The project will be stored on GitHub and all code changes will be done though pull requests. This will help us keep the codebase clean and make it easy to revert changes when we need to.

We've used Zoom for a year or two. They offer 1 Gb online storage that is convenient for sending out links to team members who miss a meeting. But some of their meetings run to 850 Mb each, which means I'm always overflowing the limit even though I don't leave a meeting up for more than a week.

So I asked about buying additional storage. The answer was that the first additional step was all the way to 100 Gb at $40/month when the basic video package was only $15/month. That's ridiculous!