HN user

EionRobb

69 karma
Posts0
Comments18
View on HN
No posts found.

The article pretty much sums up why I've been a bigger fan of OData than GraphQL, especially in the business cases. OData will still let you get all those same wins that GraphQL does but without a sql-ish query syntax, and sticking to the REST roots that the web works better with. Also helps that lots of Microsoft services work out of the box with OData.

Does that setup work ok outside in windy environments? A lot of the 'active' audio systems I've found really focus on the wind noise while hearing aids will try to filter that out

I enjoy the cat-and-mouse!

I've been writing the Teams plugin for Pidgin for the past few years and its great to be able to give users the kind of features or privacy options that you'd never get from official clients, while learning lots of fun ways (ab)using web tech to solve problems.

Like how in Teams, it does a "reverse webhook" to push presence notifications to a web client acting as a server over a websocket

We had that thought too. I'll have to try dig out what the tablets were to find out exactly what type - this would have been 3 or 4 years ago now. We sort of ruled that out because:

The other workaround to get a speed boost was the user to uninstall and reinstall the app (and then wait for all the data to download again) but that didn't fly because the users would delete before they'd synced off all their data and then data would go missing.

This was all despite having VACUUM running whenever the app started.

Whether it was bad flash or no, we still had to try resolve it as the client wouldn't buy new hardware until we could prove that we had the knowledge to make the problem go away first :/

One of the biggest contributors I've had in the past for SQLite blocking was disk fragmentation.

We had some old Android tablets using our app 8 hours a day for 3-4 years. They'd complain if locking errors and slowness but every time they'd copy their data to send to us, we couldn't replicate, even on the same hardware. It wasn't until we bought one user a new device and got them to send us the old one that we could check it out. We thought maybe the ssd had worn out over the few years of continual use but installing a dev copy of our app was super fast. In the end what did work was to "defrag" the db file by copying it to a new location, deleting the original, then moving it back to the same name. Boom, no more "unable to open database" errors, no more slow downs.

I tried this on Jellyfin dbs a few months ago after running it for years and then suddenly running into performance issues, it made a big difference there too.

Can confirm, as a Teams and Skype protocol reverse engineerer for Pidgin, that most of the Teams protocol including text messages started as Skype (not the decentralised one) and has had additional layers of stuff added over the years on top. The calling for both Skype and Teams still uses a websocket with a "reverse webhook" called Trouter, which lets the client respond to events as if it were a webserver responding to webhooks, and then does a handoff to WebRTC. When I first started writing the Teams protocol plugin for libpurple, it was easier to start with the Skype plugin than to start from scratch.

For a multi-page app, one of the important uses of serviceworkers is pre-loading and caching resources that aren't on the first page. eg you might have a background image that's only displayed three pages deep but can download and cache it as soon as the site is open.

You can potentially use http2 push to send down files from the server early but I've seen the browser drop the files if they're unneeded for that page load.

Yes, there are other hacks you could do to make the browser download the resources early, like invisible images or preload audio files, but if you're going down that path why not put in a service worker instead and have it download in the background.

Ooh we had a one of those!

They organised an in-person demo at our office after they filled in the online forms for their "multi-million dollar drinks distribution company", right in our target zone of customer type and size. So we had a few salespeople present to give a swish demo and hopefully win them over.

Turned out to be a 15 year old doing door to door sales of his home made ginger beer. He told us our (half the price of the nearest competitor) product was too expensive for what it was and that we would never succeed in business like he would.

Kudos to our sales guys though: After the initial shock and eye rolling, they treated them like the large business they claimed to be and just used the time to practice their demo/sales techniques.