Alternatives to Discord

Sentry has been essential to our development approach. Nobody likes errors or apps that crash. We use Sentry heavily during Node.js and React development. Our developers are able to see error reports, crashes, user's browsers, and more, all in one place. Sentry also seamlessly integrates with Asana, Slack, and GitHub.

Last time we shared there information about our decision about using YouTrack over Jira actually we found much better solution that our team have loved. Linear is a minimalistic issue tracker that integrates well with Sentry, GitHub, Slack and Figma which are our basic tools. I would like to recommend checking out Linear as a potential alternative to "heavy" issue trackers, maybe at enterprises that may not work but when we're a startup that works awesome!

Uploadcare is mostly remote team and we're using video conferencing all the time both for internal team meetings and for external sales, support, interview, etc. calls. I think we've tried every solution there is on the market before we've decided to stop with Zoom.

Tools just plainly don't work (Skype), are painful to install for external participants (Webex and other "enterprise" solutions) can't properly handle 10+ participants calls (Google Hangouts Chat).

Zoom just works. It has all required features and even handles bad connections very graciously. One of the best tool decisions we've ever made :)

I use Slack because it offers the best experience, even on the free tier (which we're still using). As a comparison, I have had in depth experience with HipChat, Stride, Skype, Google Chat (the new service), Google Hangouts (the old service). For self hosted, Mattermost is open source and claims to support most Slack integrations, but I have not extensively investigated this claim.

Using Screenhero via Slack was getting to be pretty horrible. Video and sound quality was often times pretty bad and worst of all the service just wasn't reliable. We all had high hopes when the acquisition went through but ultimately, the product just didn't live up to expectations. We ended up trying Zoom after I had heard about it from some friends at other companies. We noticed the video/sound quality was better, and more importantly it was super reliable. The Slack integration was awesome (just type /zoom and it starts a call)

You can schedule recurring calls which is helpful. There's a G Suite (Google Calendar) integration which lets you add a Zoom call (w/dial in info + link to web/mobile) with the click of a button.

Meeting recordings (video and audio) are really nice, you get recordings stored in the cloud on the higher tier plans. One of our engineers, Jerome, actually built a cool little Slack integration using the Slack API and Zoom API so that every time a recording is processed, a link gets posted to the "event-recordings" channel. The iOS app is great too!

#WebAndVideoConferencing #videochat

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.

Shortly after I joined Algolia as a developer advocate, I knew I wanted to establish a place for the community to congregate and share their projects, questions and advice. There are a ton of platforms out there that can be used to host communities, and they tend to fall into two categories - real-time sync (like chat) and async (like forums). Because the community was already large, I felt that a chat platform like Discord or Gitter might be overwhelming and opted for a forum-like solution instead (which would also create content that's searchable from Google).

I looked at paid, closed-source options like AnswerHub and ForumBee and old-school solutions like phpBB and vBulletin, but none seemed to offer the power, flexibility and developer-friendliness of Discourse. Discourse is open source, written in Rails with Ember.js on the front-end. That made me confident I could modify it to meet our exact needs. Discourse's own forum is very active which made me confident I could get help if I needed it.

It took about a month to get Discourse up-and-running and make authentication tied to algolia.com via the SSO plugin. Adding additional plugins for moderation or look-and-feel customization was fairly straightforward, and I even created a plugin to make the forum content searchable with Algolia. To stay on top of answering questions and moderation, we used the Discourse API to publish new messages into our Slack. All-in-all I would say we were happy with Discourse - the only caveat would be that it's very helpful to have technical knowledge as well as Rails knowledge in order to get the most out of it.

From a StackShare Community member: “We’re about to start a chat group for our open source project (over 5K stars on GitHub) so we can let our community collaborate more closely. The obvious choice would be Slack (k8s and a ton of major projects use it), but we’ve seen Gitter (webpack uses it) for a lot of open source projects, Discord (Vue.js moved to them), and as of late I’m seeing Spectrum more and more often. Does anyone have experience with these or other alternatives? Is it even worth assessing all these options, or should we just go with Slack? Some things that are important to us: free, all the regular integrations (GitHub, Heroku, etc), mobile & desktop apps, and open source is of course a plus."

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

I'm looking for advice on what App to use in conversation and phone calls to someone who lives out of the country. Should I use Google Hangouts, Google Hangouts Chat, or does anyone have any other suggestions? I would greatly appreciate any help you could possibly provide. Thank you

So I am a huge fan of JIRA like #massive I used it for many many years, and really loved it, used it personally and at work. I would suggest every new workplace that I worked at to switch to JIRA instead of what I was using.

When I started at #StackShare we were using a Trello #Kanban board and I was so shocked at how easy the workflow was to follow, create new tasks and get tasks QA'd and deployed. What was so great about this was it didn't come with all the complexity of JIRA. Like setting up a project, user rules etc. You are able to hit the ground running with Trello and get tasks started right away without being overwhelmed with the complexity of options in JIRA

With a few TrelloPowerUps we were easily able to add GitHub integration and storyPoints to our cards and thats all we needed to get a really nice agile workflow going.

I'm not saying that JIRA is not useful, I can see larger companies being able to use the JIRA features and have the time to go through all the complex setup to get a really good workflow going. But for smaller #Startups that want to hit the ground running Trello for me is the way to go.

In saying that what I would love Trello to implement is to allow me to create custom fields. Right now we just have a Description field. So I am adding User Stories & How To Test in the Markdown of the Description if I could have these as custom fields then my #Agile workflow would be complete.

#StackDecisionsLaunch

Last time we shared there information about our decision about using YouTrack over Jira actually we found much better solution that our team have loved. Linear is a minimalistic issue tracker that integrates well with Sentry, GitHub, Slack and Figma which are our basic tools. I would like to recommend checking out Linear as a potential alternative to "heavy" issue trackers, maybe at enterprises that may not work but when we're a startup that works awesome!