Agreed. My copy lost this documentation link in the original which gives more detail about the horizontal scaling: https://join-lemmy.org/docs/administration/horizontal_scaling.html.

It seems really straightforward (which is a good thing), each backend Lemmy_server handles incoming requests and also pulls from a shared queue of other federation work.

Time zones are an endless source of frustration, this one doesn’t sound too bad though:

Going forward, all timestamps in the API are switching from timestamps without time zone (2023-09-27T12:29:59.113132) to ISO8601 timestamps (e.g. 2023-10-29T15:10:51.557399+01:00 or Z suffix). In order to be compatible with both 0.18 and 0.19, parse the timestamp as ISO8601 and add a Z suffix if it fails (for older versions).

https://github.com/LemmyNet/lemmy/pull/3496

This data structure uses a 2-dimensional array to store data, documented in this scala implementation: https://github.com/twitter/algebird/blob/develop/algebird-core/src/main/scala/com/twitter/algebird/CountMinSketch.scala. I’m still trying to understand it as well.

Similar to your idea, I had thought that by using k bloom filters, each with their own hash function and bit array, one could store an approximate count up to k for each key, which also might be wasteful or a naïve solution.

PDF link: http://www.eecs.harvard.edu/~michaelm/CS222/countmin.pdf

Collage sounds really interesting , will check it out. Another variation on bloom filter I recently learned about is count-min-sketch. It allows for storing/incrementing a count along with each key, and can answer “probably in set with count greater than _”, “definitely not in set”.

Thanks for adding more detail on the DB use-cases!

Cool project and post! There’s also !flashlight@lemmy.world if you’d like to cross post.

gets hot enough to burn you if you leave it on for too long

That Fenix looks like a reliable light and is designed with temperature regulation but the limit might be pretty high and of course it is being used in an enclosure.

I am learning Python, R, and SQL

SQL is an excellent skill to invest in. Even though your current role doesn’t allow you to use it, there’s no substitute when pulling data from a relational db.

It sounds like you’re currently focused on data quality. Automatic data quality checks are common features of (good) data workflows so this could be spun as relevant experience if you end up seeking a role writing data transformation code.

Although your current role wouldn’t seem very senior at a large organizational, “senior“ is a relative term and at this company it seems like you are the engineer with ownership responsibilities over the end-to-end software development of a production system. So it might still be reasonable to use a senior title if there are other benefits

Feels odd for admins be able to prevent users from seeing content

My understanding is those admins aren't just allowing users to view it but also allowing copies of the federated data to be stored on the server those admins are responsible for, so for certain types of content it seems really important to be implemented in this way.

Focusing on code coverage (which doesn't distinguish between more and less important parts of the code) seems like the opposite of your very good (IMO) recommendation in another comment to focus on specific high-value use-cases.

From my experience it’s far easier to sell the need for specific tests if they are framed as “we need assurances that this component does not fail under conceivable usecases” and specially as “we were screwed by this bug and we need to be absolutely sure we don’t experience it ever again.”

Code coverage is an OK metric and I agree with tracking it, but I wouldn’t recommend making it a target. It might force developers to write tests, but it probably won’t convince them. And as a developer I hate feeling “forced” and prefer if at all possible to use consensus to decide on team practices.

We can’t test yet, we’re going to make changes soon

This could be a good opportunity to introduce the concept of test-driven development (TDD) without the necessity to “write tests first”. But I think it can help illustrate why having tests is better when you are expecting to make changes because of the safety they provide.

“When we make those changes, wouldn’t it be great to have more confidence that the business logic didn’t break when adding a new technical capability?”

You shouldn’t have to refactor to test something

This seems like a reasonable statement and I sort of agree, in the sense that for existing production code, making a code change which only adds new tests yet also requires refactoring of existing functionality might feel a bit risky. As other commenters mentioned, starting with writing tests for new features or fixes might help prevent folks feeling like they are refactoring to test. Instead they’re refactoring and developing for the feature and the tests feel like they contribute to that feature as well.

It’s probably not going to work as a defense against training LLMs (unless everyone does it?) but it also doesn’t have to — it’s an interesting thought experiment which can aid in understanding of this technology from an outside perspective.

Devops is not a position in itself. It’s supposed to be a software development and operations philosophy

This is the definition I know but unfortunately the term seems to have become a modern synonym for system admin/engineer.

Such a role might still provide valuable experience for a backend dev if there’s an opportunity to write production code for internal tools as well.

Developers at my company need to have a deep understanding of the environments they deploy onto (microservices, scheduled workflows, etc.) which can include configuring canary testing, rolling deployments, status probes, setting up and using monitoring, and very occasionally intervening to restart or redeploy running software. But these are secondary skills compared to writing code.