Fork me on GitHub
#off-topic
<
2021-05-18
>
Christoffer Ekeroth07:05:24

I think it needs to be an ongoing process. Programmers at any level can benefit from advice like “write short and stateless functions”, but I think it takes more experience to appreciate and use things like GoF patterns, SOLID, etc.

Mateusz Mazurczak09:05:23

@claudioferreira.dev I think the best way to learn good practices is to just write code, and then get someone experienced to do a code review, after that stick to these tips. (And it is a process, write some more code, get code review, and repeat)

Aron09:05:12

practice is key, but not enough, or rather, because there are other limits, it makes sense to try to learn from other people's endeavors before we start learning from our mistakes

Aron09:05:32

best thing is to see someone do something they are good at and try to imitate them 🙂 but when I say 'see', I literally mean see their hands while they move, how they move. Not just the result.

Aron09:05:48

If you can ask them why they do what they do and they can explain how they arrived there, that is pure gold territory.

orestis10:05:54

A mini-rant on how difficult it is to make robust systems these days, and feedback loops: We are sending emails via our platform. Like everybody else, we offload the hard bits to a mail provider (namely Mailgun). One client wants to send weekly newsletters to all their employees via our platform (whose main objective is not sending emails, but the feature is there and convenient so they use it). They have roughly 10000 employees. They send out an email to those employees. Their corporate mail servers start throttling Mailgun, which dutifully backs off and tries again, and then again and then again before eventually roughly 3000 emails fail permanently because now they're "too old". The client's IT department gives us some numbers which we're supposed to use to throttle this mass mailing, but of course we don't control SMTP connections to their servers, Mailgun does. We patch this particular issue by using a feature of Mailgun that allows you to schedule messages up to 72 hours in the future, so we managed to almost fix this error: we send 100 emails every 30 seconds. We still get throttled a bit at the end, so probably we should wait more. The big question is: how are we supposed to make this a more robust system for all clients (not just the ones who complain)? You would assume that Mailgun shoulders that responsibility as they're the email experts but their support sucks. A well-balanced feedback system would start slow and progressively accelerate email sending trying to reach an optimal point (deliver all the emails as fast as possible without getting asked to slow down or failing). But to do that you now have to write a shit ton of code dealing with an external provider's (slow) API, their quirks etc etc. So annoying. All this goes to show that things are never as simple as they seem. Thanks for coming to my TED talk.

😅 29
Aron12:05:10

to the big question: switch mail provider?

Stuart13:05:23

They are probably all shit. Everything is shit nowadays. I don't think it matters if you're only job is to provide a service that send emails, that you are in anyway competent at sending emails. Move fast and break things, pile more useless unusable broken shit into the world, hopefully get rich quick and exit before any realises how much of a massive you are. There Software Development in 2020 and beyond.

3
Aron13:05:44

I am very much on your side as experience goes, but it's one thing to assume that the neighbor will not lend their lawnmower, and it's another to not even bother to ask for it.

💯 8
Aron13:05:55

There are enough people who care.

Stuart13:05:20

I was having to use service a couple of weeks for sending SMS messages. Randomly the SMS messages would fail and they would send me back cosmoDB errors... When I talked to their support they basically said yeah, sucks. But we aren't fixing it so you will have to have error handlers to detect cosmodb errors and retry.. great

Stuart13:05:36

Why do they expect ME to deal with THEIR db errors!

seancorfield23:05:40

Reminds me of this https://www.goodreads.com/quotes/304684-i-have-always-wished-for-my-computer-to-be-as (and he said that back in the ’90s — our systems have just gotten more and more complex ever since).

marciol01:05:16

Maybe what I'll say is not related directly to the "spirit of your rant" but did you already tried SendGrid? Worked really well for me in the past. But, returning to the essential subject, it is the problem of abstractions at large, we have an encapsulated service (Mailgun) that doesn't offer a scape hatch, a lower-level API with which you can get more fine control of the email dispatching process. This is like the Language of the System talk, an orthogonal problem of Object-Oriented Programming in the large. Do it ourselves is really annoying but depending on the challenge, and of how important is some feature to the business core, we fall with no options

vncz02:05:10

I’d have my part to share here as well but it would be toooooo long. Maybe next time

Christoffer Ekeroth09:05:08

Not sure if you wanted a suggestion for a solution or if you just wanted to vent, but it sounds like the emails would be need to put on a queue, where the worker tries to send them in smaller batches and retrying whatever emails fail. Hopefully Mailgun can handle partially failed batches? But yeah, I also see the frustration - it feels like 9 times out of 10 when you buy a service to solve a problem you just end up with a different problem instead, which is dealing with a crappy service.

kenj17:05:59

Random thoughts: • Having a client demand both email delivery to all emails, while aggressively throttling you (can’t they whitelist you?) is a jerk move. I’d push back and ask them to make their email server stop fighting you if that’s really what you want. • We use a DB table as an email queue for scheduling out as far as we want into the future, which is serviced by period jobs to handle both sending, and garbage collecting entries on success after some time. This has worked quite well for us in production.

orestis18:05:25

Our clients and their IT are not always easy to work together. We usually provide better support (which is why they pay us) :)

Eccentric J22:05:25

Any cool frontends out there written with ClojureScript?

marciol01:05:33

https://penpot.app/ is a really interesting open source project, entirely written in ClojureScript

Ben Sless05:05:53

Does logseq count?

dharrigan05:05:26

This is all written using clojurescript and clojure: https://kpow.io/

Eccentric J05:05:07

Thanks all! These are great

👍 2