Clojurians Log v2

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.

@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)

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

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.

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

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.

to the big question: switch mail provider?

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.

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.

There are enough people who care.

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

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

Any cool frontends out there written with ClojureScript?

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).