off-topic

https://github.com/clojurians/community-development/blob/master/Code-of-Conduct.md Clojurians Slack Community Code of Conduct. Searchable message archives are at https://clojurians-log.clojureverse.org/
Kenneth Gitere 2021-05-18T04:27:22.000200Z

thank you

Christoffer Ekeroth 2021-05-18T07:19:24.002100Z

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 Mazurczak 2021-05-18T09:19:23.005100Z

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

Aron 2021-05-18T09:23:12.006400Z

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

Aron 2021-05-18T09:24:32.007400Z

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.

Aron 2021-05-18T09:26:48.008Z

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

orestis 2021-05-18T10:42:54.016100Z

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.

10😅
Christoffer Ekeroth 2021-05-19T09:44:08.024700Z

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.

kenj 2021-05-25T17:48:59.131Z

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.

orestis 2021-05-25T18:04:25.132400Z

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

2021-05-18T12:23:04.017500Z

I think "cleanliness" is a terrible way to approach this. what we actually need is readability - code where the first intuition of the human reader leads you to the author's intent. it's a question of human communication not mechanical hygiene. my preferred angle is that "optimization" is a vector space (you can optimize for memory usage, CPU usage, startup delay, portability, long term maintainability, short term time to deploy ...) and the most powerful optimization is to optimize for human readability. that optimization is fungible - it's the only one can trade it in for any other optimization. it introduces technical investment while all other optimizations introduce some form of technical debt.

1👍
Aron 2021-05-18T12:24:10.018200Z

to the big question: switch mail provider?

2021-05-18T12:24:30.018400Z

it's more of a literary skill. the ability to convey quickly and accurately what it means to a human reader.

2021-05-18T12:25:37.018600Z

I'd say it's best picked up via repeated code review (both reviewing the code of others and communicating with them about their intent, and having code reviewed by others and answering questions about your intent). there's quite a lot of empathy to it.

2021-05-18T13:08:23.018800Z

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.

1➕
Aron 2021-05-18T13:17:44.019Z

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.

2💯
Aron 2021-05-18T13:17:55.019200Z

There are enough people who care.

2021-05-18T13:20:20.019400Z

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

2021-05-18T13:22:36.019600Z

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

2021-05-18T22:44:25.021Z

Any cool frontends out there written with ClojureScript?

rakyi 2021-05-19T08:34:49.024200Z

https://github.com/athensresearch/athens

Asier 2021-05-19T13:31:20.025400Z

http://pitch.com

vemv 2021-05-19T13:38:49.025600Z

https://github.com/CircleCI-Archived/frontend (TIL it's archived... whoops)

2021-05-19T15:40:29.026300Z

https://oNote.com

2021-05-20T05:15:07.028700Z

Thanks all! These are great

1👍
seancorfield 2021-05-18T23:29:40.021100Z

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