Yeah but no one is doing a one day rental on the 4 cars they want to drive. Not to mention finding the exact make/model they are looking for.

If I’m interested in a car, I’ll try and rent one for a few days on Turo. It’s a great way to see what it’s like to actually live with the car. I’m never buying without renting again.

I thought of this idea recently as well. You pay $20 bucks or whatever and get to drive X number of cars, book your time slot online, etc.

You would have to have enough volume to justify the inventory that is sitting on your lot. And what if someone wants to test drive a 2017 instead of a 2018 or a 2014 etc... The number of combinations of various makes, models, and years, seems like you could never cover the overhead and be profitable unless you specialize in specific niches.

Zoom doesn't use WebRTC (which the article is about). They use websockets to send media through the pipes and decode using a webgl shader or similar.

I don't work for Zoom, but do work in the WebRTC space and read an article about it recently.

Gotta link for that? Sounds really neat

https://webrtchacks.com/zoom-avoids-using-webrtc/, perhaps?

Zoom has to be using h264 under the covers. Did they recompile the OpenH264 into WASM?

like: https://github.com/kazuki/mediacodec.wasm

It could also be that they are using websockets to deliver MPEG-DASH/HLS segments for low latency.

I've never heard of or experienced #1 and have been in the industry for 8 years. We all break shit. That's not a reason to pass on junior devs.

In regards to #2, it's not that you won't add value until you are fully trained, but there are X number of people applying for the same position, and as the person doing the hiring you are going to try to get the most experienced developer you can for that role.

There are still plenty of good companies that go out of their way to hire junior devs (for budget or other reasons)

This is a good idea. You listen on some publicly available endpoint that doesn't have access to your internal network, you vet the messages you receive and push it to a message queue.

Then your server running on the internal network manages to connect and pull messages from that queue.

I was looking for a way to get performance metrics around custom events (API calls, time for X component to render, etc) . Essentially like console.time only with pretty graphs and in the cloud across all users. I don't have access to our backend services directly (lots of microservices owned by other teams) so I started exploring this idea.

I put out some feelers to friends and there was some interest so I stood up a landing page to see if there is any actual demand here.

I was looking for a way to get performance metrics around custom events (API calls, time for X component to render, etc) . Essentially like console.time only with pretty graphs and in the cloud across all users. I don't have access to our backend services directly (lots of microservices owned by other teams) so I started exploring this idea.

I put out some feelers to friends and there was some interest so I stood up a landing page to see if there is any actual demand here.

I was looking for a way to get performance metrics around custom events (API calls, time for X component to render, etc) . Essentially like console.time only with pretty graphs and in the cloud across all users. I don't have access to our backend services directly (lots of microservices owned by other teams) so I started exploring this idea.

I put out some feelers to friends and there was some interest so I stood up a landing page to see if there is any actual demand here.

If you add an overflow:hidden to your content section, you won't have that wonky extra space to the right. That's just a quick fix. I didn't look into why it was happening.