steffres

4 ms·

1.
by steffres 2y ago
Forgot to add, that those can be concatanated, e.g. `__o_car__t_finances`.
2.
by steffres 2y ago
I do this manually by appending `__t_tag`, where `t` is a category and `tag` the value. E.g. `__o_car`, where `o` means object, or `__p_supercode`, where `p` = project, `__t_ml`, where `t` = topic, ml = machine learning, etc. No dependencie
3.
by steffres 3y ago
I simply rinse my wooden boards with boiling water after cutting meat on them (and then wash them of course).
4.
by steffres 3y ago
oh, you're right. I forgot that a key characteristic of anything being "declarative" is that order of statements should not matter. Acutally, come to think of it, since `RUN` may depend on any other Dockerfile statement (even
5.
by steffres 3y ago
I didn't mean to use Django _and_ a separate migration tool. It's just that I did work with Django so far, but switching now to a new codebase without it. Hence my question for experiences in DB migration.
6.
by steffres 3y ago
I see. Thanks for the clarifications. And these DB migrations, did your team keep a history of them? If so, did you manage them yourselves, or did you use some tools like flyway? I'm asking because I'm starting a project where we
7.
by steffres 3y ago
That sounds reasonable. But what about the case where the DB migration of version 2 would be incompatbile with code version 1, e.g. a column was dropped?
8.
by steffres 3y ago
I'd say both. Some is declarative, e.g. `FROM`, `ENV`, `EXPOSE`. While on the other hand `RUN`, `CMD`, etc. is fully imperative.
9.
by steffres 3y ago
yes, if one submodule would depend on another, this would cause problems indeed. So far, we could avoid it though, by strict encapsulation. But I definitely see the point in your example and wouldn't follow through with submodules ther
10.
by steffres 3y ago
In our case, we have a codebase that involves two submodules: one for persistence and one for python based management of internal git repos. Both of these are standalone applications and can run on their own. They are then used in a parent
11.
by steffres 3y ago
for each submodule affected by some change you would need an additional commits, yes. But those commits are bundled together in the commit of the parent repo where they act as one. So, atomicity of changes can be guaranteed, but you need to
12.
by steffres 3y ago
Anyone know, what's the advantage of this over a big composite repo with several git submdolues? I think that submodules are better suited for separation of concerns and performance, even while achieving the same composite structure as