Historically this has been my approach, but in production environments it’s convenient to have a static list of variables with no “export” instead since eg systemd’s EnvironmentFile only supports that.
614 karma · joined January 11, 2018
Historically this has been my approach, but in production environments it’s convenient to have a static list of variables with no “export” instead since eg systemd’s EnvironmentFile only supports that.
Doesn't this just mean they own the rights to their use as a logo? Eg the stylized X on their products? I don't think this blocks anybody from using X in their products as long as the logos are clearly different.
I was probably too harsh in my initial message, but when I read the article and see reasoning along the lines of “git lacks a good UI for X, I hear there may be 3rd-party solutions to this problem, but then that’s too many things to install, so I’d rather build a custom solution from scratch which does everything”, it reminds me of stuff I see at work ;)
I know git has a learning curve, but the only times I really see junior people have issues is when they are trying to do things that wouldn't have been easy with earlier VCS systems either. And it seems like git isn't going away, so it's worth putting the time into learning it.
If you don’t like the lack of a good GUI or web application, you can just build one that works the way you want and still works with git.
I also think this discussion shouldn’t be about languages at all, you can have objects of some form in any imperative language including C. It’s more about what design patterns make sense for specific problems, and sometimes the answer is OO-style (eg with class hierarchies) and sometimes not.
Going to have to review my REST APIs to make sure that’s not a problem.
This doesn’t have anything to do with MVCC. I’m sure PostgreSQL could implement an index format that piggybacks on another index rather than pointing at the physical page directly, without overhauling MVCC.
Most comments about debugability are nonsense. It’s just different, with some pros and cons. One simple example - if you have a bug in production, you’re not going to attach a debugger to your production application. But you can absolutely open a readonly connection to the database and start running queries, invoking functions, etc. It helps if you can architect your functions to distinguish pure readonly functions from those with side effects, but you can still debug even if that’s not the case.
Perhaps something like “X|!Y” or similar might be impossible?
Adding extra fake noise to the movie solves a few problems such as ensuring a consistent look from scene to scene, as well as avoiding video artifacts like banding.
It’s also an artistic choice just like the choice to use telephoto lenses that blur backgrounds into fuzzy balls of light.
So I don’t understand what’s different here.