snikch

Fixed. Thanks for the report.

Sounds dangerous.

I have used tools like these for nearly a decade and find them invaluable. My current favourite is Mailpit [1].

The “OG” I would consider Mailcatcher [2] from my Rails days

[1] https://github.com/axllent/mailpit

[2] https://mailcatcher.me/

My Apple TV didn’t come with an HDMI cable. It’s required to work. The difference I guess is Apple don’t make the cable?

Did they check the source of the request? My guess would have been an extension doing this instead of the site.

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.

Your form didn't work for me :(

Wow, what trash. The text rendering makes it barely readable, and dragging a card around lags out and then it follows where your cursor was 5 seconds ago until it catches up.

I've had the same situation and reward, but just on a normal non prime day.

Yea I came to ask that same question. All I can assume is that’s badly reported and in fact entire cell tower’s messages were being tapped. Which has huge repercussions for privacy. Another thought could be some sort of forwarding service. Regardless these numbers are massive.

I use NordVPN for my home server's docker containers, on my phone and on my Mac. Never had any issues and it's v. cheap when purchasing for 3 years.

It's MySQL

Looks really interesting. I'm getting a 503 on the Google auth though :(

I feel like this is an incorrect, inflammatory title. New integrations will cease to work with TLS < 1.2. Existing integrations are fine.

There's spelling mistakes everywhere, and the top navigation doesn't appear to work. How are we supposed to take this seriously?

I think this method is much more healthy for you.

Hrm, no I hadn't. I don't know much about this command. Could you give me a (thawing) example?

I use the yes command to defrost my lunch. I open up a couple of tabs running

yes > /dev/null

Then place my frozen lunch on the back of my macbook. Give it an hour or so and boom, defrosted.

I've got two automations that were life changers.

1. Whenever I start watching Plex on my TV, my home automation turns off the lounge light that reflects in the TV. 2. If it's after 11pm, the fire is on and we're not playing music on the stereo, it means I've left the fire on - so it gets turned off.

Amazon's Aurora databases seem to be solving the same problem, and are MySQL or Postgres compatible to boot.

Poli now manage this via an API with Westpac at least, i.e. you go to Poli, redirect to Westpac and log in, then redirect back to Poli who pull in the info with an API. Very much like an OAuth flow, but I don't know the actual details of it. (I won't get into how oauth isn't a great solution, but at least I'm not exposing my creds to Poli).

AWS doesn't do containers? I think that's a mistake.

Not sure this is an issue as you don't make http requests TO the app.

This may definitely be a concern for some organizations, but I think there's a lot of focus on serverless being all about apis and web requests. Serverless is also a great way to manage stream processing, and job queues - where these issues are less relevant.

Fair enough - there are definitely use cases where I could see that making sense. I love the value lambda provides for early stage, when every penny counts.

Heroku gives you servers, but manages them for you - so you have long running processes, for web or worker etc. Lambda allows you to have the process run for literally the lifecycle of the job (request, streaming job etc.). In fact, your job can't run for more than a few seconds or it is terminated. Heroku charges you for the hours your dynos run - but what if they're idle most of the time? You still pay for them - not with lambda.

I think you're missing the point of the 'serverless' part, as Kong still requires you to have a dedicated server to run it. One of the early stage benefits of the serverless architecture and AWS's api gateway is that you don't have to pay for resources that you don't consume - so if you've only got a small amount of customers, you don't have to pay for dedicated instances to be running.