jholloway7

Now that you mention it, this might be why my family stopped playing Rack-O with me

Could they calculate and show an estimate of the monthly charges based on current objects in the bucket before and after the change in storage class? OP may still have clicked through w/o heeding, but I can see that as a potential improvement to the warning message where a user would then be forced to understand why it didn't affect pricing in the way they assumed it would.

Noted, thanks. Didn't realize that was the issue.

If your aunt had nuts she'd be your uncle

Downvotes on comp sci 102. Nice.

You can write a list data structure with performant 'delete' properties if you're willing to maintain a sort or a hash table. There would be people here bitching about memory usage if the stdlib did that natively. Here's a solution: don't use list.delete. You're using the wrong data structure if that's your solution to whatever collection you're maintaining.

This problem transcends documentation of any given language's standard library. list.delete(value) in any programming language is a degenerate without an ordering or hash built-in to the underlying data structure.

If you ever need to delete based on value, it's a smell that a list is the wrong data structure. I'm sure there are cases in constrained environments where a linear search is heuristically okay, but generally in application development list.delete(value) is a hint that you're using the wrong data structure.

Yep, it makes it easier to port the JRE to platforms like Windows that have an entirely different TZ system. Python, for example, has the same problem. Historically, Python took the stance of providing a "naive" datetime module that provides a conversion API, but delegated the actual TZ conversion to external implementations (dateutil, pytz). Only recently (as of 3.9) have they added a stdlib implementation that uses system-level zoneinfo by default.

Not sure if lower-level API of RQ supports this, but I tend to prefer message-oriented jobs that don't couple the web app to the task handler like the example.

I don't want to import "count_words_at_url" just to make it a "job" because that couples my web app runtime to whatever the job module needs to import even though the web app runtime doesn't care how the job is handled.

I want to send a message "count-words" with the URL in the body of the message and let a worker pick that up off the queue and handle it however it decides without the web app needing any knowledge of the implementation. The web app and worker app can have completely different runtime environments that evolve/scale independently.

> a ton of consumers

So like 12 average adults? /s

I'm not sure how you read from my comment that I'm saying 'this shit is impossible'. I'm simply saying in many organizations 'how fast the intern got it up and running' is not always a valid indicator of how ready it is to be deployed to a few thousand concurrent users.

For example, large MMO guilds have a quite different regulatory environment from, say, a large healthcare organization in the US governed by HIPAA. It's an extreme example, sure, but a homegrown, dumbed down solution, might be the only way to ensure regulatory compliance.

It doesn't take a lot of imagination to come up with other scenarios. I can't defend Uber doing it because I'm not involved, but large MMO guilds are not archetypal of enterprise systems.

My comment isn't concerned with using 'personal' time for such endeavors. My concern is with the implicit conclusion that how fast you can get something up and running (a 'weekend' in this case) is an argument that you can and should deploy a new stack in any given enterprise.

You'll find a lot of times the champion of the new hotness moves on and leaves someone else to maintain the old hotness at costs that were never factored into the original deployment.

As I noted in another comment, it's a trilemma where you have to pick and choose your battles. The initial deployment time is rarely the most important factor when introducing a new stack within an organization.

I'm not necessarily in the 'build one from scratch' camp either, I'm just pointing out that there's a trilemma in enterprise systems. How fast you're able to get something up and running is just one factor and not always the most important one.

You're making a good underlying point but contriving way too many details in your argument for it to be taken seriously.