Excel files can work surprisingly well in B2B scenarios where there's a high degree of trust. At a retailer I used to work at, we ran an impromptu Christmas gifts team in December each year, where corporate clients could put in a large order of gifts to be sent to their employees. Rather than build a website for it, we just sent them over an Excel file they could fill in with the name and address of each employee, the gift they wanted to receive and a message for the label. They'd send the file back to us and we had a process to validate the data and load it into our system. It sounds primitive, but it was much more time- and cost-efficient than faffing around with a custom application that we would only use for one month per year and which the clients probably wouldn't enjoy using anyway.
A malicious user who had the knowledge and ability to craft expensive GraphQL queries could just as easily use that knowledge to tie your REST API in knots by flooding it with fake requests. Some kind of per-user quota system is going to be required either way.
The Cradle adaptation is only an animatic, sadly. Best case scenario is that it generates enough buzz for a Netflix or an Amazon to pick it up for a full series, but then I'd be worried it would get butchered like Rings of Power or Wheel of Time have been.
Don't forget deploying updates by either (a) stopping your Python application and then restarting it, hoping your users are not too badly inconvenienced in the interim, or (b) rigging together some kind of blue-green deployment setup. Meanwhile, the PHP developer runs rsync and the deployment is done.
In 10+ years of professional PHP development, the only time I've ever had to fix a codebase while updating the PHP version was when mcrypt was deprecated, and it was only around half an hour of work to replace it with a modern equivalent, including the time to re-encrypt the data.
Meanwhile, I've had the misfortune of inheriting a React application that would no longer build a mere six months after the original developer left the company. I've come to loath working on React projects due to the insane amount of library and tooling churn in that ecosystem.
Re: Lightyear, a $226.4M box office return on a $200M production budget isn't even close to being in profit, tiny or otherwise. For one thing, a film's marketing budget isn't included in the production budget figure and in this case was probably $100M+ itself. Secondly, Disney do not receive 100% of the box office take. After the distributor's cut, it's probably closer to 50%. Films of this type need to make maybe 3 times their budget at the box office to break even, making Lightyear a spectacular flop.
It looks like this service is intended to replace the kind of random "notify us of a missing manhole cover" type forms that are found in their thousands on government websites. For those types of applications, emailing the form to a relevant mailbox is probably the correct thing to do, and in many cases it's the way the existing forms already work. Only a small fraction of government services will have their own custom backend application supporting them.
I'm not a gamer myself, but my wife is and she frequently points out the creaky door sound effect when we watch movies. It's amazing how often such a small set of effects is reused.
Nevertheless, the headline is 100% accurate. Perhaps the problem here is that the catered event rule shouldn't apply when the venue is inside a stadium.
Generally, when you see a package asking you to install it globally with `npm -g i`, you can install it locally with `npm i` and then run it with `npx`. Requesting global installation is either an expression of ego or the author is a Python refugee.
> Why does it matter if a program is a self-contained binary? It seems like such an odd requirement.
Because sometimes I just want to write `my_program | your_program` without learning how to install and set up a program in a language I don't personally use, particularly when that language has the worst packaging ecosystem of any mainstream language.
The mistake was to think Perl was suitable for those types of applications in the first place. Perl was designed for writing small scripts to glue C programs together in a more convenient way than using shell scripts and AWK. A lot of its idiosyncratic design decisions make sense in that context. But when Perl advocates starting pushing it for writing large applications with OOP (with, of course, multiple competing object systems) it was the beginning of the end. Add in the vapourware that was Perl 6 and it was game over.
Outside of the US, iOS's market penetration is so low that unless your app sells luxury yachts, it's largely pointless to throw your dev resources behind it no matter how well-heeled your Apple customers may be.
Hyperbole. Advertisers backed away from Twitter because Musk was upsetting a group of people whom advertisers tend to tiptoe around. Twitter is terrible, but it's no more terrible now than it was when Musk bought it.
> One of the reasons behind the popularity around webapps was that they would no longer need to make 'a server call' on each interaction.
Ironically, many modern SPAs are significantly slower than the traditional apps they replaced. Try using Twitter's webapp on a non-premium phone, for example.
Sometimes it's regrettable that the webdev truck has no rear-view mirror.
You realise you've been arguing with multiple people expressing multiple opinions, right? You appear to be prone to binary thinking, so it might not be clear to you that your opponents don't form a single monolith.
> tl;dr if you're not offended by 4chan they're not actually saying anything offensive about you even though it might appear so superficially; 4chan just has a different list of things you can't say.
I'm not offended by the things 4chan users say because I don't visit 4chan. You should try it yourself. Getting so upset by words you disagree with on one forum that you feel the need to froth at the mouth about it on another forum doesn't seem healthy.
I feel this way about the "David Bennett Piano" channel on YouTube. He discusses various music theory topics, illustrated with examples drawn from pop and rock songs. In particular, he often singles out Radiohead as being a source of music-theoretic innovation in rock music - it's quite clear he has considerable admiration for them. The thing is though...I'm not sure if it's always the case that Radiohead were consciously using a particular scale or meter on a given song, or whether it's simply that they were out of tune and played sloppily. Some of the rationalisation being presented on the channel feels like a stretch, particularly in Radiohead's case.
I think the solfege for Baby Shark would actually start with sol la do, or in the key of C, G A C. Because the phrase eventually ends by dropping down one semitone on the final "shark", which would end up being F# (Fi!) if you started at the root of the scale. The initial movement from G to C, or sol to do in solfege, is very common and something you spot everywhere once you're aware of it.
The issue isn't the exact syntax that's used to access the service object. It's the fact that any random chunk of code anywhere in the codebase can reach out to any other random piece of code. Syntactic sugar or not, that's considered to be an antipattern in pretty much any community outside of Laravel's.
> I don't know why but any game that [...] has complex controls just loses me immediately
For me, the cutoff point is any game that requires combinations of button presses. The Xbox controller already has a crazy number of buttons. Any game that requires me to e.g. press the left stick down while simultaneously pressing the shoulder button is just an instant no. I remember abandoning the latest Doom game for this reason - it was just too much.
> there should be a market for games where I can just jump in, have 30 minutes of fun by myself, and log off
I've been playing Spelunky 2 for most of the last year for precisely this reason. Randomly generated levels, runs that last less than 15 minutes (sometimes seconds!) and gameplay that's simple to pick up but which has considerable depth when you get into it.
This is true for backend frameworks too. In the PHP world, Laravel contains many helper functions that uselessly duplicate functionality already available in the standard library. Not only is this a waste of effort from the framework's author, it also unhelpfully silos some developers into Laravel-specific knowledge. I had a colleague who had worked professionally as a Laravel developer for several years but then failed a job interview because he'd literally never written a vanilla PHP script and had no idea how to go about it.