Add https://mailsnag.com to the list. You can share email samples with others for the review and it also allows receiving emails for your prod env - send emails to your app and process them in it.
The idea is that, in a a test environment, we should not actually deliver the mails to the recipient, instead making them available on a web page (or through an API).
An API driven approach like Msgdrop is more flexible, as many apps can’t configure a fake SMTP server, especially if you use tools like Mailgun or SendGrid.
I read this after making my own post that starts the same. This sums up my thinking too so elegantly. There are so many aspects to code and how it gets written that inform the output that each needs to be viewed in the context of that. Was it time critical? Was it part of a legacy migration? Was it a complex problem?
The quality of the code doesn’t have to reflect the quality of the solution and we should celebrate the things we nail.
Yes! I do! But they’re never the parts I think they’ll be. Sometimes it’s the simplest of things like a nice CRUD api that’s bounded and neat. Sometimes it’s a horribly complex system with well known trade offs and intricate guarantees. I love looking back and thinking “yea I got that right” or seeing an abstraction that’s stood the test of time (my six year old report query definition and data table responses in a reporting system is one concrete example I’m proud of, but I’d rename some fields for sure). I have a few of these that I’m so proud of if I really stop and consider it. On the flip side, the majority of projects teach me something that I wouldn’t do the next time, hence the common “old code sucks” trope. I think it’s important to recognise when something worked as much as when something didn’t. It’s these successes that give me the confidence to try things a little outside the box if I think it’s for the best.
I’m loving jitsi, I’ve built a prototype video party app this week focussed on lockdown parties and fixing the things that don’t work for big parties over video chat. We’ve had a couple of parties on it and boy has it performed admirably.
However, there’s a big “but”. The documentation is abysmal. I’m sorry but that’s the cold hard truth. It’s been a nightmare to understand the pieces working while also using their libraries. Incredibly hard to read, and incomplete, docs. I’ve had to refer to the source to try figure things out most of the time. I say this because I think there’s soooo much potential there if it was more accessible. If you’re from jitsi and are keen for some good and critical feedback then hit me up, I’d love to help you out.
I've been thinking about this too. In fact I've started hacking on an app to solve this for my group of friends. To me the two primary issues are:
1. Sub groups without losing the context of the full group. I want to focus on a set of people and chat with them while also aware of what other groups are around. I want to be able to bring people into these groups at will. This also adds a gamification aspect where you can adjust groups, i.e. randomly mix, mix people who haven't talked to each other yet etc.
2. Multi monitor. I want to see everyone and real estate is limited on a single screen. I should be able to add multiple windows or computers to my chat and have everyone spread across those windows. Only one window / computer will submit video and audio for me though.
There was a jit.si post on here where someone made a 2d map. If you were standing close to them on the map you heard the if voice. Further away people were ignored.
If I remember right there was an app from the early 2000s that did something kind of like this. It would be cool to combine the 2D map with a speech-to-text word cloud over clusters of people so you could see if you wanted to join another conversation.
I really prefer it to discord/whatever other voice client because you can also do stuff like hierarchical broadcasting, a parent channel can broadcast to children without children broadcasting back.
There are a few Minecraft mods that implement this kind of behavior, and I could swear I saw it baked into a shooter game somewhere but I can't remember which one.
What if your chatting was also at a lower volume for other groups so if one group organically disbands, can pre-hear what some groups are talking about to join in. Feels like a pretty natural experience in social gatherings.
>Sub groups without losing the context of the full group.
Different 'rooms'? You could keep the video tiles for all people on screen organized by room, then the individual chooses which one to join for audio. You could include a push-to-talk 'announce' button to send your audio to all rooms in addition to the normal open mic in the room you belong to at that time.
I picture a mosaic of webcam feeds that have border lines drawn to indicate group members.
