I think we have enough anecdata that users don’t like a changing interface. They like keeping things the same, mostly.
So how can you keep generating disposable software on this layer?
And what you mostly want to change in software, is new features or handle more usage. If you do that, it needs in most cases changes to the data store and the “hand crafted core”.
So what part in practice will be disposable and how often will it be “generated again”?
Maybe for simple small stuff, like how fast Excel sheets are being made, changed and discarded? Maybe for embedded software?
> So how can you keep generating disposable software on this layer?
Well... If your "users" are paying customers of a XaaS Subscription service, then there's propably little need and/or room for disposable UI.
But if you're doing something for internal processes with maybe 2-3 users at max, then you might want to do something that does not result in launching an under-budgeted project that could be a full blown SaaS project on its own.
I think embedded software would be like the anti-case for OP's idea. It's a resource-constrained environment, and you also cannot upgrade things easily, so the "replaceable" parts of the software become nothing.
This reminds me of the story where Barclays had to buy bad assets from the Lehman bankruptcy because they only hid the rows of assets they did not want, but the receiver saw all the rows due to a mistake somewhere. The kind of 2% fault rate in Excel that could tank a big bank.
I don’t think this is universally true. At least not here in the Netherlands, but even in visiting the US it does not feel like that everywhere.
I think it is very sad the moral standards are so low. I find that even harder when mixed with “why does the government get involved in everything?” attitude.
I also don’t lead my company of 27 people that way.
Too often I see the attitude of "I can't believe a company would do that". Personally, I always believe it. We know companies will do everything within the law to make money, as is their purpose for being, and we also know they will break the law if they think they can get away with it. Not all companies all of the time, but we are fools if we don't expect it from some companies some of the time and on a consistent basis.
It actually reminds me of a Dutch policy (which may be apocryphal, please correct me) wherein prisoners in the Netherlands do not face further penalties for escape attempts because they are simply engaging in the only natural behavior we can expect from a person in a cage.
It is not “companies” but individuals. But yes, there are a lot of people that are only driven by greed and power. But not all by a long shot. I believe most of society would fail if everyone was doing the maximum they could get away with. So, there should be a lot of people that don’t seek the maximum they can get away with.
But I agree that a lot of companies are so big and so faceless, that they do too much bad stuff and lots of people in the company would just shrug it off with “it is not my job to say something”.
>It actually reminds me of a Dutch policy (which may be apocryphal, please correct me) wherein prisoners in the Netherlands do not face further penalties for escape attempts because they are simply engaging in the only natural behavior we can expect from a person in a cage.
This is my philosophy as well, which is why I as a juror would be soft on "crimes against law enforcement" because being a cop is part hunter, and do you expect all your game to not attempt evasion?
These blanked statements about monoliths are what made every junior dev think that microservices are the only solution.
If you cannot make a clean monolith, I have never seen any evidence that the same team can make good microservices. It is just the same crap, but distributed.
The last 2 years I see more and more seasoned devs who think the opposite: monoliths are better for most projects.
Yes, but also - more difficult to refactor, more difficult to debug (good luck tracking a business transaction over multiple async services), slower with network overhead, lack of ACID transactions... Microservices solve problems which few projects have, but adds a huge amount of complexity.
I tried a setup with Nginx Unit and php-fpm inside a Docker container, but the way to load the config is so combersome I never was confident to use it in production. It feels like I am doing something wrong. Is there a way to just load a config file from the filesystem?
We're very actively working on improving Unit's UX/DX along those lines. Our official Docker images will pick up and read configuration files from `/docker-entrypoint.d/`, so you can bind mount your config into your container and you should be off to the races. More details at https://unit.nginx.org/installation/#initial-configuration
But that's still kinda rough, so we're also overhauling our tooling, including a new (and very much still-in-development) `unitctl` CLI which you can find at https://github.com/nginx/unit/tree/master/tools/unitctl. With unitctl today, you can manually run something like `unitctl --wait-timeout-seconds=3 --wait-max-tries=4 import /opt/unit/config` to achieve the same thing, but expect further refinements as we get closer to formally releasing it.
> We’ve mapped the source config/ to /docker-entrypoint.d/ in the container; the official image uploads any .json files found there into Unit’s config section if the state is empty.
I am building https://github.com/claceio/clace. It allows you to install multiple apps. Instead of messing with routing rules, each app gets a dedicated path (can be a domain). That way you cannot break one app while working on another.
Clace manages the containers (using either Docker or Podman), with a blue-green (staged) deployment model. Within the container, you can use any language/framework.
> The control API is the single source of truth about Unit’s configuration. There are no configuration files that can or should be manipulated; this is a deliberate design choice
So yeah, the way to go is to run something like `curl -X PUT --data-binary @/config.json --unix-socket /var/run/control.unit.sock http://localhost/config/` right after you start your nginx-unit.
The way to manage a separate config step depends on how you manage to run the process nginx-unit (systemd, docker, podman, kubernetes...). Here's an example I found where the command is put in the entrypoint script of the container (see toward the end): https://blog.castopod.org/containerize-your-php-applications...
I did that, but sometimes it takes a short moment before Unit is started, so you need a loop to check if Unit is responding before you can send the config. In total it was around 20 lines just to load the config. It feels like doing something wrong. Or using the wrong tool.
I like restful API’s the most. Graphql is cool if you need data combined that is not nicely available in the restful endpoints. But I think that could mostly be solved with good endpoints that help with the actual use cases. When restful endpoints are hard to use, in a lot of cases it is because they are to much focused on how it is easy to write server side, then it is to consume them.
Yes he has. I have seen multiple episodes on his YouTube[1] where he absolutely grills the whole company. He also gave them a deadline to opensource the drivers or he would stop trying to make AMD stuff work.
Sorry for no direct link, but he has so many and very long videos that it is hard to find the exact spot.
So how can you keep generating disposable software on this layer?
And what you mostly want to change in software, is new features or handle more usage. If you do that, it needs in most cases changes to the data store and the “hand crafted core”.
So what part in practice will be disposable and how often will it be “generated again”?
Maybe for simple small stuff, like how fast Excel sheets are being made, changed and discarded? Maybe for embedded software?