As far as their public website tells (https://www.riec.nl/) the RIEC is about a targeted bundling of knowledge, experience and resources to better deal with the effects of organized crimes, instead of everyone working in their own little silo.

The "interventions" are basically the forming and supporting of work groups / special interest groups around a specific organized crime phenomenon, with the intent of devising an approach to deal with the specific phenomenon. They publish a report of those so-called interventions here: https://www.riec.nl/documenten/publicaties/2024/12/18/interv...

My comment is made from the background of someone who has led the effort of bringing software development in-house, building a 20-odd FTE dev team, and is still leading it 3 years in.

I'd not bring everything in-house at once unless you really have to. Your fear that the devil is in the details is very much justified (I have stories, boy, do I have stories ...). However, in your position I would definitively start building a dedicated tech team. That allows you to start developing real solutions to solve pain points in a way that feels less like "filling the gaps" and more like "the first steps towards a better future". It also may make you a better, more informed customer which may perhaps help with your current vendor as well. It also gives you something to fall back on if the proviable shit really hits the fan with your current vendor.

Do not underestimate the importance of product management. Product management drives your development team. If you now use a basically off-the-shelf product, this is likely taken care of for you. Or not, given you describe the vendor as stagnant. In either case, you need to have that covered well.

One-is-zero: do not rely on single individuals, build a team. At the leadership level you'd want at least a product lead, business analyst, cto and a senior software architect. Make sure they work together as a team and that there is healthy cross-over in expertise/experience so that people can cover for eachother. In-house, not contracted.

I'd advice against fully outsourcing to an agency. You can contract a development team, and depending on where you are located that may be the most realistic option, especially in the beginning. But make sure you are at the steering wheel and have the people and experience in-house to use that wheel well (see previous point).

Invest in boring things like documentation and testing right from the beginning. It will pay for itself many times over. If you let it slide, you'll never catch up and you'll pay for /that/ many times over.

Other than that there's probably a lot I've learned from my adventure so far, but I find it typically difficult to assess what the lessons learned are unless someone pokes me with the right questions. Feel free to reach out at my HN username @ mailbox.org.

Product management is really important and must not be delegated too far down. As main sponsor you need to be involved as well. A lot of key decisions must be made and ability and power to say no is vital as is the ability to move the other parties around your system at least a little once in a while.

Were you at the company before they brought things in-house, or were you brought on for that job explicitly?

I haven't been in this situation before, but I imagine one of the trickier challenges in a role like what OP is describing is that whoever leads this also needs the ability to manage scope for the team, including persuading the existing COO or whatnot that "yes, we _could_ bring this in-house but you really really do not want to."

This is a disingenuous comment at best.

As explained in the docs you link to, Postgres has both synchronous and asynchronous replication modes.

In asynchronous mode availability is favored over durability. Which means commits can get lost when the primary goes down in an uncontrolled fashion.

In sync mode that will not happen at a cost to some performance.

It’s the same trade-off any distributed system has to make, and the user gets to make the choice.

MySQL can actually do one better which is semisync. The transactions get replicated synchronously but applying them is async. You can't lose data anymore due to a primary failure.

Postgres has a similar feature, if you chose ‘remote_write’ for the ‘synchronous_commit’ setting.

You can also mix and match sync/ascync options within a cluster and even between individual transactions.

Recent versions of Postgres have a really flexible replication configuration to cover a whole range of requirements. See e.g. https://www.postgresql.org/docs/current/warm-standby.html#SY...

There was once actually an active effort to remove magic from Django: https://code.djangoproject.com/wiki/RemovingTheMagic

Good point. Most of my experience with Django was on and after the 0.96 release

Exactly this. For the docker images we use in production, we fork the corresponding git repo, build our own image and push it to our own local docker registry and pull it from there. It's fairly easy to setup in fact.

Out of curiosity do you resolve it so that the image is FROM scratch or do you rely on alpine/some other base image?

I forked an ubuntu image and then used it as a base for all my projects. It doesn't come for free though, you will need to periodically run security updates and then rebuild all images that depend on it.

You might be able to proxy the dictionaries from your own server? Unless something in the t&c's of the dictionary providers prohibits you from doing that of course.

I thought about that but don't like the idea:

1. As you say, could be against t&c.

2. Tons of requests for the dictionary page coming from my server's IP address may lead to being blocked.

3. The user can edit the URL template to fetch any site they like, and I don't like the idea of my server fetching content from any arbitrary website.

4. Would add extra bandwidth and load on my server.

Hmmm I've a distinctly different experience. In my experience their support is good and their engineers quite knowledgeable. Tickets are dealt with within reasonable time frames. If I really do need something to happen quickly, I can call in and have someone knowledgeable on the phone within 10 minutes, who often will do whatever is necessary right away. During a recent issue they had two engineers in two time zones working on it, to shorten the time to fix as much as possible (still took a long time, but it was a difficult issue so ...).

Basically. The idiomatic solution for this in python is:

  def fn(x, my_dict=None):
     if my_dict is None:
         my_dict = {}
      ...

You can use a sentinel if you want to allow None as an argument. More on that, along with a way to use mutable defaults productively:

http://effbot.org/zone/default-values.htm

Well, that's the million dollar/euro question isn't it? It's a bit hard to verify with all the secrecy going on. And arguably without some level of secrecy you cannot have effective intelligence. It's a bit of a catch-22.

In fact the Dutch owned New York once (then called New Amsterdam ;-) until they effectively traded it with the British for Suriname and some spare change.

And that whole Dutch East Indies and Indonesia thing still has some repercussions till this day.

The Dutch still have parts of The Netherlands overseas, including people that can vote in the Dutch elections, along with territories that are overseen not by the Dutch government but by the King (used to be the Queen).