abhibeckert

I run a service that sells theatre tickets and, far more critically, a service to check if a ticket is valid or not.

Tickets are checked, by scanning a QR code, as people walk though the door. Not only do people hate sitting in their seat waiting (or worse, standing in line waiting)... you also need to pay a couple hundred employees to stand around and do nothing while waiting - ballpark cost of wages might be $5 for every second you can cut from the process of people walking through the door. On top of that wages cost, people waiting for the show to start don't buy drinks at the bar. A lot of events make more money on drink sales than ticket sales... often a high percentage of ticket sale revenue goes to whoever has a copyright claim to the show. They often get a cut of drink sales too, but it's a smaller cut.

So there are strong incentives to start scanning tickets as late as you possibly can before the performance actually starts. And if there's 1 second of downtime... it might trigger ten minutes of troubleshooting (turn it off and on again, etc) by a dozen people.

A show starting ten minutes late can be _really_ bad. If the show prep starts at 6pm and show pack up finishes at 11pm, that's five hours where some people are working non stop throughout that time - it's not really OK. Live events are dangerous, workplace deaths are far too common and some of the steps taken to try to prevent them don't really leave room for someone to take a meal break during a show. Alec Baldwin was shot and killed by a "prop" gun, in part because crew took a meal break at a critical time on the set, which interrupted routine safety checks... stuff like that can, and does, happen in theatre too.

There are union rules around breaks that everything is planned around and because delays happen in the real world there are financial penalties in place to discourage delays. So instead of $5 per second, that ten minutes might cost you $20 per second... in other words a $12,000 cost that wasn't in your budget... and the producer will have to explain why they ran $12k over budget - keep in mind the show might not actually make $12k profit in a single night's performance. Sometimes they don't even make a profit when they run smoothly.

All of that means your one second of downtime will be followed a formal written incident report and meetings to discuss what happened, and those meetings will inevitably include investigating alternative ticket services. We know little things like that can cost us a fortune, because we win new customers all the time when they tell us they left a competitor after a single brief period of downtime (our biggest competitor recently had a bug where buying tickets didn't work in the shitty browser that ships with certain cheap android phones... they fixed it relatively quickly but we gained a lot of new customers anyway).

Sure - it's only that critical from, say, 7:30pm to 7:55pm in a single building... an hour of downtime at 10am wouldn't be noticed... but if it's a global service, with dozens of cities in every timezone, then that critical state is happening 24/7/365.

One second of downtime will absolutely cause a measurable, and large, cost to your company profits. We deployed a major new system for ticket scanning in February last year. It worked perfectly, we haven't made any changes since February - other than just testing it out, and we're starting to deploy it over the next two months. That's how reluctant we are to break things.

We considered PostgreSQL, but decided it's not reliable enough.

We're using SQLite - with literally thousands of databases — every hand held scanning device as well as the servers run their own database. The servers themselves have a separate database for each individual event (and there are redundant servers too, so multiple server side databases per event). Also the database for critical things like scanning tickets is a separate database to less critical things, like payment records, event details, etc.

PostgreSQL is better than SQLite for the servers at least in a bunch of ways - but the big advantage of SQLite is flexibility - we can do a phased deployment where from the moment we start selling tickets (a few months before the actual event) to the moment of the actual event, there will be no deployments at all to that database unless we think a bug will directly effect the event. A deployment today will typically only apply to events that go on sale starting tomorrow.

Every business case has different needs, but skim reading this article on the future of Postgres, it sounds like they're working to improve some of the reasons I chose not to use it for this specific case.

Why charge $10, when you can charge $10 per month?

But seriously, Beeper does have server side components. They're just optional ones. If you don't pay, you don't get those features.

Modern CPUs are fast, and it's trivial to scale compute instances if you need that.

The database would be the bottleneck and that's got nothing to do with rails - it's all mysql.

Having built similar software, at a smaller scale, I think you're massively overestimating the complexity of shopify.

At it's core, what they provide is (largely) read only set of products, and a (largely) append only set of purchases.

The only write operation that needs to lock the database is when you adjust the quantity of available inventory. You need to pay attention and think things through to do that with good performance, but it's not that complex. and they wouldn't be doing millions of sales per second.

That's like arguing there's "no value" in a business that sells pizza.

I mean, anyone can just make their own pizza. Where's the value in someone else doing it for you?

The limit is it doesn't do filenames or other metadata — it's limited to contents.

For the benefit of everyone else reading this discussion who doesn't speak Swedish... here's what I got from a good (paid) translation service:

"Force majeure typically refers to war, riots, fire, natural disasters (such as floods, hurricanes, earthquakes), explosions, strikes, new laws prohibiting the fulfillment of the contract, and similar events."

The thing is though, Tesla isn't suing because their license plates aren't being delivered. They are suing because it was* literally impossible for them to access an essential government service.

(* was, because Tesla has won a preliminary decision forcing the state to allow Tesla to arange an alternative delivery method - probably Tesla sending someone around to the factory to pick up the plates)

In my opinion Force Majeure would only be a valid defence if it was the number plate factory workers who went on strike, but that's not what happened. The number plates are there, ready to go, and the state refused to allow Tesla to access them.

Force Majeure is not a blanket blanket right to do whatever you want. It only defends you in cases where you had no reasonable alternative available due to the strike.

I'm reminded of a time when flooding closed a railway line that I'd bought tickets for... the railway company didn't argue force majeure and cancel everyone's booking. They hired a dozen busses. You have an obligation to find a reasonable solution if the service you'd normally provide isn't possible.

In my case, the train service was 100% aware that they had a low bridge over a river that floods whenever there is heavy rain and therefore they couldn't argue that it was an unforeseen event. They would have been liable, not only for the cost of the train ticket, but also for any other damages/etc suffered by someone who was suddenly unable to get where they needed to go (booking a flight or regular bus wasn't possible, those don't have enough spare capacity for an entire train full of people). In this case, there is a perfectly reasonable and zero cost alternative to having license plates delivered by their usual method, and they can't refuse to use that alternative.

As someone who lives near a beach in a warm climate... I've never seen anyone wear one of these nor have I seen them for sale in stores.

I can't imagine when I'd wear one either - if I want protection from the sun I'll wear a hat or sunscreen - not a hood.

This. The main system memory on a Mac Studio is GPU memory and there's a lot of it.

It also has the Neural Engine, which is specifically designed for this type of work - most software isn't designed to take advantage of that yet, but presumably it will soon.

The main problem with OAuth is it's a three party system.

You have an API provider service, an API client service, an a human telling the provider that the client should be allowed to access a limited subset of data on the provider service.

That's fine in cases where you actually need three parties involved, e.g. an API that allows access to a user's photo library stored in the cloud... but that's not every situation and if you can avoid it, you should.

A simple two party system, where the API provider authorises the API client, is vastly simpler. And just as secure (more secure even, because complexity is the enemy of security).

> there wasn't a cost effective power solution for just desalination

There absolutely is.

All you need is a bunch of mirrors to direct the sun at a chamber filled with water. The water will evaporate, the expansion into steam creates significant pressure so you can run it through a turbine, and then once the steam cools down and liquifies again, it won't have any salt in it.

It's not even remotely expensive. Mirrors are cheap. The turbines/etc are basically the same as a coal or gas power plant and mirrors are a hell of a lot cheaper than mining coal or gas. Also if you're boiling a usable quantity of water you'll be generating a lot of power, which is a handy byproduct (more valuable than the water to be honest).

"Not in our back yard" is the real issue. The chamber is generally at the top of a tower, and even painted black all that sunlight focused onto it is very bright. People generally don't want a really bright object on top of a tower anywhere near them. I guess you could build a wall around it or something, but you'll still get complaints from aircraft/etc.

Driving into the sunset or sunrise is annoying. Imagine if that was all day every day instead of just for 20 minutes or so.

Having said that, if you're in a remote area to counter the NIMBY issue, and clean water is hard to find, then the system I've described is very effective and they are being used for cost competitive farming of cheap crops.

Anyone who actually wants to desalinate seawater can do it. It's just that almost nobody wants to right now.

Reminds me of PHP 6...

For those who don't follow PHP closely - that version was an attempted refactor of the string implementation which essentially shut down nearly all work on PHP for a decade, stagnating the language until it became pretty terrible compared to other options. They finally gave up and started work on PHP 7 which uses the (perfectly good) PHP 5 strings.

Ten years of wasted time by the best internal PHP developers crippled the project - I'm amazed it survived at all.

I work at a consulting firm.

Our salary is loosely linked to what percentage of our work is billable (with leniency for inexperienced staff, who aren't expected to be profitable while they're learning their craft).

If you spend three hours figuring out why things fall apart on the 31st of the month... that generally can't be billed to the client, and therefore it's bad for your salary.

On the other hand, if you spend three hundred hours writing tests and implementing an awesome multi-stage deployment process that avoids one production bug a month? Your manager can totally bill that work (with the right client).

That list would be nowhere near complete.

For example my brother lost a vessel in a hurricane - he was bunkered down on the mainland and it was gone after the storm - we assume the storm surge lifted the anchor off the seafloor and it floated to who knows where and wrecked.

It wasn't insured, so wasn't reported. I suppose it's possible someone stole it, but I can't imagine anyone would be brave/stupid enough to do that during a hurricane.

Maybe someone somewhere in the world got lucky enough to see a drifting abandoned vessel and claimed it... but that's pretty unlikely.

> HDR can't give you more range, so what does it actually do?

It does give you more range.

A lot of modern screens literally can't run at their full dynamic range, they would draw too much power and/or get too hot (some professional displays I use at work have a power cable as thick as your thumb and radiate heat like an oven with the door open. They also require following warm-down procedures to prevent the electronics from failing if they cool down too quickly when you power them off).

They can, however, run at full brightness for a small section of the display or brief periods of time. HDR videos are one way to instruct the screen to do that.

(obviously, how much range it can give you depends what screen technology you have - Apple's software has supported this for a long time, but even some current model displays they sell can't really do HDR properly - though many that "cant" to HDR are able to make a best effort using complex software tricks)

Both QR codes are using #ffffff.

The "bright" one has metadata that tells the operating system to render white at the maximum possible brightness, instead of whatever brightness it would normally render white at.

It's broadly supported on Apple devices, though how well it works depends on the hardware you have.

It's pretty common in meatspace for communities to have membership fees.

I'm part of a community theatre that charges members $20 per year. The membership fee makes you legally a shareholder in the organisation for that year, with voting rights at an annual election where new management is voted in.

There's usually only 50 or so people who vote (most members can't be bothered), so $20 gets you a substantial amount of influence if you can be bothered.

Last year's management are required to step down before the vote starts, making them regular members with a single vote during the re-election process. Usually it's mostly the same people voted back in, but there's always two or three new faces each year.

That knife cuts both ways - Reddit hasn't paid anyone to write valuable content for their platform, which means they don't really own the content and it can be taken away.

A lot of people are leaving reddit over this.

> Connect via USB to a PC as a mass storage device

... if you want a mass storage device... buy a mass storage device?

Personally I'm happier with the cloud though. I want all my files in the cloud anyway as an offsite backup, and the internet is generally fast enough that I can access the remote copy whenever I need it.

> Be switched on immediately when plugged in, after the battery runs out

My battery never runs out though.

But seriously iPhone CPUs are pretty power hungry with 3.46Ghz with six cores and aside from just booting up there's also some pretty high decryption going on to decrypt and verify the operating system hasn't been tampered with. I'm pretty sure a USB cable can't provide enough watts.

> Want to use a keyboard/mouse/monitor to control your phone instead of your thumbs

USB and Bluetooth keyboards totally work with iPhones, and iPads. I use a mouse and keyboard all day long every day with my iPad (I'm happy with my thumbs for my phone, but I could use the keyboard for that too).

And you can absolutely connect it to an external screen too, with HDMI or over a network connection.

The file picker is terrible.

I pretty much never use it on my Mac, all the apps I use show the filesystem in a sidebar and have a fuzzy search feature. Even Apple apps (like Xcode) have that so clearly they're aware of how bad the file picker is.

The SPA's we create can be reliably linked to (the current URL changes as the user moves around, even though the page hasn't reloaded) and they are "stable" because our business would go bankrupt if Google couldn't crawl our content.

If Google can crawl it, then you can too. And while Google doesn't use a headless browser (or at least I assume they don't) they absolutely do execute javascript before loading the content of the page. And they execute the click event handlers on every link/button and when we use "history.pushState()" to change the URL Google considers that a new page.

You're just going to get a loading spinner with no content if you do a dumb crawl (I disagree with that and think we should be running a headless browser server side to execute javascript and generate the initial page content for all our pages... but so far management hasn't prioritised that change... instead they just keep telling us to make our client side javascript run faster... imagine if there was no javascript to execute at all? At least none before first contentfull paint)

In my opinion the only way to use it safely is to ensure your AI only has access to data that the end user already has access to.

At that point, prompt injection is no-longer an issue - because the AI doesn't need to hide anything.

Giving GPT access to your entire database, but telling it not to reveal certain bits, is never going to work. There will always be side channel vulnerabilities in those systems.

Last year a tiny radioactive capsule the size of a fingernail went missing in Australia, when a "safe" storage container the size of a small car failed and allowed it to fall out.

The search to find the capsule cost four million dollars and there were global news stories warning people to avoid the highway the (very, very long) highway the truck had driven down.

In other countries (e.g. Soviet ones) where precautions like that haven't been taken, those capsules have been found after dozens of people caught cancer due to regular exposure to a capsule that just happened to end up near them. Presumably there are more that haven't been found, and those countries just accept a higher rate of cancer than the rest of the world.

Avoiding those scenarios is what costs so much.

The only subreddit where I saw a vote, it was something like 95% of people voted for a blackout. Almost nobody is siding with reddit on this.

The cost is something like $500 per user per year. People just aren't going to pay that much.

Admittedly I haven't written any ruby code in a very long time, but you only briefly touched on the reason we ran away from it after giving it a serious try:

> rails devs pay the bills with other tech or by maintaining legacy rails apps

That "maintaining legacy rails apps" job just doesn't exist with our PHP apps. Once properly tested and deployed PHP will generally work perfectly and smoothly for years with zero maintenance unless someone finds a bug that was missed in testing. You can pretty much setup a cron job to apply security patches and that's it. Maintenance done.

The only downtime I can recall was when our datacenter installed buggy firmware on their storage array and brought down every virtual machine we had with them... which was a pretty rare and unusual event (by the time they fixed it, we had already moved everything to another datacenter... and it seems we weren't alone because they went bankrupt).

With ruby that wasn't our experience at all. We found our production code would regularly just stop working and resources had to be pulled off other tasks with zero notice to figure out why/fix the issue. It was a productivity nightmare. Maybe that's improved now, but from reading the Shopify and GitHub blog posts they both seem to be taking on mammoth amounts of work to ensure their systems are reliable.

At the companies I work for (more than one) we expect anyone qualified to do work like that to be dedicating all of their time to other things. All of the apps we built in ruby were rewritten from scratch in PHP and we haven't had any regrets.

I've never really liked PHP and I actively hate JavaScript, but I've come to accept those two languages are just more practical than anything else. I'm definitely keeping an eye out for that to change though - Swift is look promising for example.

What is this doing in the first example in the readme?

> open https://api.github.com/repos/lmorg/murex/issues

As a Mac user, I'd expect that to launch a web browser, but it appears to be downloading and parsing the JSON?

BBEdit was known for that in the past, but it's a weak point these days. It definitely has an upper limit on filesizes and will "choke" on large files (probably only slightly larger than the log files you're using it for).

Other apps are much better at large files. The APFS filesystem has a maximum file size of 8 Exabytes and plenty of other text editors can handle file sizes that large without any issues.

The gateways I use don't, or at least give me the option not to.

Those iFrames cause all kinds of headaches when the user hits the back button or double clicks a submit button or does any number of other things that happen thousands of times a day on a moderately high traffic site, and when it messes up you either miss out on a sale (ouch) or charge the customer twice (double ouch).

Built in sun shade is totally a thing - there are umbrellas with a built in clamp to attach them to just about any chair. And they work fine as rain umbrellas too.

https://www.outbackadventures.net.au/product/oztrail-clip-on...