The only word really not sitting totally right with me so far is Projectile because it says too much without saying enough. Versus vectoron that entity, which I feel is perfect for now, and the Shell concept, which frames what's fired. It's like the digital version of:
A puzzle well presented is half solved.
The Shell namespace handles the framing of what's needed; whether Request or Response depending on if it's coming in or going out; or Contact #13 or a Trigger #12. Rather than the idea of those being "targets" which the system is trying to "hit" which puts the focus on the tool, the "need of the moment" is seen as the "format of action taken" ... which goes into why Projectile is too brute a word, and not kinetic enough. I picture the kind of shell that has its destination written on it, because it's more personal. It's not a random shell in storage, waiting for action.
Within the shell of the rocket or mortar is the capacity for an explosive reaction which can be expended in a strategic and focused way. That's more about the shot than "what is fired" in importance, especially when the "actual situation is taking place" digitally. It's not a projectile, but it sure is a shot. And by this one metaphorical word being taken out, projectile ... the rest of the words which were metaphorical become literal ... it's a Shot we're writing.
As before with include Celluloid being the mark of an actor, include Artillery::Shot is the mark of a microservice.
Dipping back into vectors on Shots now vs. vectors on Projectiles ... it's way more quantum physics feeling and less game-physics feeling.
Right now there are things like this:
module Revolution
class RiseUp
include Artillery::Shot
vector :get, "/*
def initialize shell
#de take action
#de work toward `fire!` which is like `return` but allows #4 continued execution of the launcher
#de if this were baseball or golf it would be "swinging through" the strike
end
end
end
And what would be added with a lot of implications but simple notation:
All this separate definition of those things is for the birds. Having to go to a separate file to set intervals in a separate scheduler, or channel mapping and routing location, etc... takes the mind off what you're actually writing, and breaks the microservice up into pieces when just like with .vue files on the interface side, the entire thing ought to be a small file, but still contain literally everything involved in that shot.
The only word really not sitting totally right with me so far is
Projectile
because it says too much without saying enough. Versusvector
on that entity, which I feel is perfect for now, and theShell
concept, which frames what's fired. It's like the digital version of:The
Shell
namespace handles the framing of what's needed; whetherRequest
orResponse
depending on if it's coming in or going out; orContact
#13 or aTrigger
#12. Rather than the idea of those being "targets" which the system is trying to "hit" which puts the focus on the tool, the "need of the moment" is seen as the "format of action taken" ... which goes into whyProjectile
is too brute a word, and not kinetic enough. I picture the kind of shell that has its destination written on it, because it's more personal. It's not a random shell in storage, waiting for action.Within the shell of the rocket or mortar is the capacity for an explosive reaction which can be expended in a strategic and focused way. That's more about the
shot
than "what is fired" in importance, especially when the "actual situation is taking place" digitally. It's not a projectile, but it sure is a shot. And by this one metaphorical word being taken out,projectile
... the rest of the words which were metaphorical become literal ... it's aShot
we're writing.As before with
include Celluloid
being the mark of an actor,include Artillery::Shot
is the mark of a microservice.Dipping back into
vectors
onShots
now vs.vectors
onProjectiles
... it's way more quantum physics feeling and less game-physics feeling.Right now there are things like this:
And what would be added with a lot of implications but simple notation:
All this separate definition of those things is for the birds. Having to go to a separate file to set intervals in a separate scheduler, or channel mapping and routing location, etc... takes the mind off what you're actually writing, and breaks the microservice up into pieces when just like with
.vue
files on the interface side, the entire thing ought to be a small file, but still contain literally everything involved in thatshot
.