SSO is not a requirement for secure software. It’s a requirement for enterprises because otherwise they have to manually keep track of everyone’s accounts everywhere, but that’s a management issue not a security issue (unless managed poorly).
Admittedly for many SaaS and OSS offerings SSO is an enterprise-only feature while it doesn’t have to be, but it’s the best discriminator they have to separate cheaper plans from enterprise plans. The alternative is to charge more for all plans, but then you lose out to the competition that does play this enterprise tax game.
I was hoping for some interesting insight to be shared, but no it’s just a shallow opinion piece on why E2E is better than unit tests for web interfaces, without really explaining why.
The author misses that component tests don’t have to be like unit tests at all, they are more like integration tests if you test entire pages (which are components too), use actual user interactions and mock only the I/O (mostly network) layer. It’s like E2E without spinning up a backend.
Why this is getting blamed on JavaScript / Node.js is beyond me. Microservices were/are all the rage in Java/Scala land, and seemed to initially be pushed by (Dev)Ops engineers' desire to roll their own Kubernetes cluster (or whatever came before). I've been on multiple such project and I always loathed the additional complexity (especially combined with actors/event sourcing and Cassandra). Node.js was limited to some frontend tooling that only ran locally or in CI.
LAN parties got me into casemodding. I was always more interested in looking cool (to this particular crowd) than actually playing games [1]. I always picked a seat at the end of a row, close to the catering so people would come over to take a look.
This quickly got out of hand with sponsors (Cooler Master, Silverstone, among others) and dragging my builds to casemodding contests and trade shows (CEBIT Hannover). I was still in high school. Good times.
Is nobody concerned with the fact this tool scans your repository contents? This tool is mostly intended for use with private projects, not open source, so I would expect a LOT more scrutiny (and options) around security.
The "free" in FOSS is about being able to use the software as you see fit, without restrictions. Not that you don't have to pay a dime. Sure in practice the software is usually "free as in beer" but that's a side-effect, not a goal (or guarantee).
We help developers build UIs with components. We maintain Storybook, the most popular open source tool for developing UI components. To fuel our open source work we build Chromatic, a cloud service for Storybook that automates workflows for UI feedback, visual regression testing, and documentation. We’re open source veterans previously involved with Apollo GraphQL and Meteor. We're currently hiring for the following roles:
So true. I was involved in two very different Scala projects. One was the sensible "better Java" way, which was mostly great. The other was a big enterprise project with a core group of "hardcore" FP enthusiasts which was very stressful because of imposter syndrome and troubles to onboard new folks. I have been against Scala ever since, exactly because of this FP cult.
Wow, I was really expecting this to be an argument against FP, until it wasn't. I love the concept of designing for Thursday 5pm though. My approach to achieve that is simply different (it doesn't include FP).
I read the whole thing waiting for the aha-erlebnis which never came. I'm a full stack JS/TS engineer with a decade of experience. I expected this article to be written for someone like me. It didn't click, even though I already love and use functional aspects like immutability and pure functions. I feel like it's the whole new set of terminology that puts me off (and I'm talking about `scan` and `Task`, not even `Functor` or `Monad`). I have confidence I can learn and apply this in a few weeks, but I can't realistically expect junior/medior devs to quickly onboard into a codebase like that.
Maybe I'm biased against "true" functional programming because I've been on Clojure and Scala projects in the past (as a backend dev) and both experiences have been good for my personal/professional development, but a shitshow in terms of long-term project maintenance caused by the enormous learning curve for onboarding devs. The article talks about how great it is for confidently refactoring code (which I bet is true) but doesn't talk about getting people to understand the code in the first place (which is still a requirement before you can do any kind of refactoring).
My only hope is for ECMAScript (or maybe TypeScript) to introduce these OK/Err/Maybe/Task concepts as a language feature, in a way which befits the language rather than trying to be "complete" about it. We don't need the full spectrum of tools, just a handful.
I own a Nissan Leaf and can confirm 90km/h is about the sweet spot for trip duration. Above it, you're draining battery faster than you can recharge it. Below it is unsafe on motorways. I usually set it at 104km/h, which makes the estimated range pretty much exactly match reality.
However, for newer EVs the sweet spot will be at higher speeds, because those cars are able to recharge at much higher speed (at least 2 times faster).
We use Lambda@Edge to build our own CDN on top of S3 with authentication, so our customers have reliable, fast and secure data access. We use a bunch of edge lambdas which serve thousands of requests each minute, so I suspect we'll see a nice cost reduction with this.
Some of the stuff we do:
- rewrite urls
- auth and permissions check
- serve index.html on directory indexes
- inject dynamic content in served html files
- add CORS headers