dvlsg

NFTs probably will too, so I suppose that's at least one similarity between the two.

> It's unfair and pointless to expect SOLID (or anything else) to apply in any and all cases.

I think that's a big part of the problem, and how we end up with articles like this. A lot of developers do expect SOLID to apply to every case, and I've seen fine code get rejected in reviews because it wasn't SOLID enough.

The difference is that reddit at least tries to moderate calls to violence and hate speech.

They don't always do a good job of it, though.

Yeah that's correct. The built-in implementation of Promise violates some of the interfaces monads need to follow, including that auto flatten. But it's definitely possible to have a monadic promise (or future or whatever).

I can't say I agree with that. There is a lot of really good new music, just like there is a lot of bad old music. The difference is the bad old music has already been forgotten, but the bad new music is recent enough to still be somewhat memorable. For now.

Yeah, specifically that interfacing with the ui causes some side effects we would expect to happen (web hooks sent, reports generated, etc). I definitely wouldn't want to write all of our tests that way, because that sounds like a nightmare to maintain and run, but was considering a handful for covering a few major features. We do already have a very extensive backend integration test suite (http / rest interactions) that doesn't do anything with UIs, though.

Cypress is a recent addition for us, so this is more a curiousity than anything else. I've done similar fully e2e / functional tests with puppeteer in the past.

Our backend is in node / typescript, so it's theoretically possible to mix the two. I would be able to test what I need using REST APIs, though, so in theory the backend language doesn't really matter for me.

I haven't had much time to try anything yet, but cypress's override of promises and async / await makes me think it'll be a pain to try adding non-cypress-specific checks to a cypress test.

Did you ever need to mix cypress tests with anything else? Say for example I wanted to have cypress click through a frontend, and then make a separate backend call to verify something happened in the same test run. Is there a clean way to do that in a cypress context, or is playwright / puppeteer going to be a better fit?

That is pretty nice.

I've been doing `git push -u origin HEAD` and then using my mouse to click on the "go here to create a PR" link that gets printed, which isn't too bad. Takes you right to the page where you can review the changeset before opening the PR. If I'm not actually ready to open a PR by the time I push upstream, I just open a draft instead.

Luxon makes for a good date lib stop gap while tc39 works on something built-in that is (hopefully) a bit nicer.

https://moment.github.io/luxon/

https://tc39.es/proposal-temporal/docs/

Would you mind expanding on some of the operational complexity you ran into with pulsar?

I think pulsar is wonderful, but I haven't had the chance to use it for anything serious / in production yet, so I'm curious what pain points you had.

Manual testing is an important thing to consider, for sure.

Who does QA on the feature branches, and where? Does each feature branch have its own corresponding deployment? Are they sharing databases with other branches?

I think it's still fairly young, but Gleam is an ML family language that works with the BEAM. Specifically, it compiles to erlang.

Tenkeyless is the sweet spot for me. Still has arrow keys, but the numpad is gone.

Ian's secure knot is great, too.

I suspect the start time is meant only for classes, not extra-curriculars.

How so? I'm not seeing the benefit over exporting A, B, and C as functions, and then putting them together in another spot (like a composite root for pure DI, or an IoC container, etc).

Is the argument for top-level await that you don't need the other spot? Because I feel like you still do - except now it's implicitly inside not only A, but likely B and C as well to some extent. And in a very inflexible way.

Which features were missing for you with CircleCI? My experience with CircleCI has been almost entirely positive so far.

His biggest contribution may be the documentation and defining the vocabulary, but when he defines a pattern with a word that has an obvious negative connotation ("anemic"), it feels manipulative.

A while ago I was told by members of a separate team that I was writing the core of my javascript application incorrectly. I was following "functional core, imperative shell"[1] and intentionally separating my data from my functions[2]. Specifically, the code was considered to be wrong because it was "anemic", and I was sent a link straight to that 16 year old page about anemic domain models[3]. The suggestion to fix was to add a bunch of mutable state.

Don't get me wrong - I still almost always appreciate Martin Fowler's writing, as it's often quite good, including the original post. But I also understand some of the skepticism here.

---

1: https://www.destroyallsoftware.com/screencasts/catalog/funct...

2: https://softwareengineering.stackexchange.com/q/203077

3: https://martinfowler.com/bliki/AnemicDomainModel.html

Sure, I probably should have specified that I meant in general when handling money, not necessarily specifically for handling payment API calls. I've worked on a system that kept track of arbitrary precision separately while using integers to store the values. Worked reasonably well, all things considered.

But you're right, we wouldn't have expected to be able to call something like stripe with that same arbitrary precision. It was all internal pricing.

Or even just regular cameras. If I take a picture of something unrelated, and the background happens to contain a license plate on a car, or the face of a person walking by, am I at risk for recording a person's identifiable information?

Probably worth noting that in some cases the currency alone isn't enough information.

For example, gas stations using USD often use more than 2 digits of precision.

I suspect (and hope) that situation is reasonably rare, though.

Lenses in ramda work well, too, if you don't mind being functional in your js code.

I suppose that still only fits in the "immutable by convention" category, though.

How would you handle ci/cd with docker compose on an ec2 instance?

Then you can't use it across apps, though.

Say for example you have a web front end, a mobile app, and a service receiving web hooks that all want to execute the same action. If you have that in a client layer, you'll be writing it 3 times.

Moving logic to the client comes with pros, too (like being easier to work offline), but it definitely has downsides as well.

I have to admit I'm a little surprised the entire form wasn't cleared on a failure.

F# is good for this, too.

It _kind_ of works in typescript, but it's not enforced by tsc. Definitely helps readability, though.

Can confirm that's how it's happening in Iceland, too.

Took a tour up there a while back, and our tour guide stopped to yell at people putting themselves in life threatening situations to take pictures. Happened multiple times.

I agree that practicing slow is helpful. Certainly helps my drumming quite a bit.

And not only mixing up slow/fast, but loud/soft, too.

Why would they block you from downloading windows if you're already on windows?

For what it's worth, I successfully downloaded that windows iso from microsoft less than a week ago from a windows machine, and used it to reformat that same machine without any issues or workarounds.