Things the domain expert on the author's example cant tell (from the top of my head):
- is the app is properly deployed
- how will the release cycle be
- is it secure?
- can we run two instances of it without messing up the orders/routes/whatever?
- will we spend 5k/month in vercel if people start using it
- how will we notice service degradation
- if we change the data do we have downtime? how do we schedule that downtime window.
- where is the code stored? can the team access it?
- how are new contributors onboarded?
- does the app use credentials and where to store them?
- does the app manipulate or store PII?
- if the user refreshes the app does it generate a duplicate order/route/whatever?
- if there's an upstream service are we making sure our timeouts are properly configured?
- if there's an upstream service are we making sure our connection pool is properly configured?
- do we have a max connection lifetime so that middleware like AWS NAT or ALB don't leave us with dead connections in our pool?
I think that makes the point clearly. Also it may explain why software developer jobs are currently on the rise despite SWE-Bench-Pro-Ultra-Magic has been maxxed for months now.
Can't believe people is so eager to believe in this without any real scientific publication of vaccine efficacy.
Cuba lacks things so common as soap, to the point that you can bribe police officers or even pay sex workers with a tiny hotel soap bar or shampoo flask.
Is it doing a weird maneuver on 1:32 or is it just me? Something like stopping right after turning. I'm not full aware of the USA transit laws so this might be required but it doesn't seem likely.
That's a ton, you're probably not using typescript incremental compilation feature but recompiling your whole codebase instead. Even in that case, 7 seconds for compiling a 100k LOC code base is not even close to what I call "slow".
I disagree. Typescript is an excellent example of an optional static type system that works great. It has none of the 3 problems the OP describes: it's fast, it nicely encompasses the whole language and the Definitely Typed repository includes a TON of 3rd party library type definitions.
There's simply no technology that makes you switch from 30 machines to 1 (you say you keep 2 just for reliance).
Obviously there must be other architectural changes in play here (I'm guessing RoRs thread-per-request vs some kind of event loop on Go?). Please be more specific.
It borrows a lot of concepts from rails. I think that no "conversion" tutorial is needed, if you give it a shot it won't be long until you find yourself at home again.
Speaking strictly about the website redesign, I think that (although nice) it fails to communicate the framework biggest selling points. Some comments on that:
* The code-save-refresh workflow: this is mentioned briefly as "hit refresh workflow" which is confusing to say the least.
* Some other weird or 'meh' bullet points like type-safety (you're using either scala or java so you take that for granted) or stateless-web-tier.
* The introduction video is long. It's fine as a tutorial, but being the first thing you can click on I expect you to sell me the framework in 2-3 minutes or so (it can be done, play is fantastic).
Disclaimer: I love play and used it a lot last year. In fact I was part of the team that put the first play application into production on LinkedIn (featured in the bottom of the play site).
It relies on the fact that you can provide javascripts String#replace a "replace function" (1). The author just evals the contents of a command line provided file into a variable called `replaceFunc`.
Beside that, there's not a lot that can be pointed out as "bad", at least by just reading it lightly (5-10 mins).
- is the app is properly deployed - how will the release cycle be - is it secure? - can we run two instances of it without messing up the orders/routes/whatever? - will we spend 5k/month in vercel if people start using it - how will we notice service degradation - if we change the data do we have downtime? how do we schedule that downtime window. - where is the code stored? can the team access it? - how are new contributors onboarded? - does the app use credentials and where to store them? - does the app manipulate or store PII? - if the user refreshes the app does it generate a duplicate order/route/whatever? - if there's an upstream service are we making sure our timeouts are properly configured? - if there's an upstream service are we making sure our connection pool is properly configured? - do we have a max connection lifetime so that middleware like AWS NAT or ALB don't leave us with dead connections in our pool?
I think that makes the point clearly. Also it may explain why software developer jobs are currently on the rise despite SWE-Bench-Pro-Ultra-Magic has been maxxed for months now.