Name my class
-
When in doubt, just name it Steve. It's a nice name.
This from the person who completed his account name by mashing the keyboard when his own name wasn't available...
-
Is the following your project class naming convention by any chance?
Steve
Steveasjmj
Steveasjmjasjmj
...
-
Where did you find my production code?
-
-
Next time someone laughs when I say one of the hardest things in programming is naming components correctly, I'll point them to this thread.
Unless you're Boomzilla, then you just name whatever "import" and people magically know what it means.
-
Unless you're Boomzilla, then you just name whatever "import" and people magically know what it means.
Yeah, sure. I'm the one having trouble with the meanings of words.
Filed Under: Invade Cuba now
-
When in doubt, just name it Steve.
His name is Gorak!
<Now to find out who the South Park fans are…>
-
-
just name it Steve. It's a nice name.
Billy is a horrible name for a drone, and Steve is even worse.
https://www.youtube.com/watch?v=05UGYjB4Tyo&t=1m11s
-
His name is Robert Paulson.
I was in a band once called Robert Paulson. At our first (and only) show, the lead singer starts the set by saying "Hello everyone! Our name... is Robert Paulson". Without prompting, about half the audience said in unison "Their name... is Robert Paulson". Best crowd ever.
-
-
If this thing is hard to name because its behaviour is unusual, that might actually be a clue that there's a better design to achieve the ultimate end.
If your concern is that you don't want to overwhelm clients with updates, might you be better off having the clients pull them from you rather than you pushing them? There is a standard name for an object that captures only the latest update and which clients can examine at their leisure: it's a scoreboard.
-
If this thing is hard to name because its behaviour is unusual, that might actually be a clue that there's a better design to achieve the ultimate end.
If your concern is that you don't want to overwhelm clients with updates, might you be better off having the clients pull them from you rather than you pushing them? There is a standard name for an object that captures only the latest update and which clients can examine at their leisure: it's a scoreboard.
Hmm, no. That would screw up the case where nothing is happening and client keeps pooling in vein.
Remember, in most of my use cases, upstream is fast (local RAM), while downstream is behind the IO swamp. So it makes sense to rate limit on my (local) end, instead of making remote clients long-pool through network.
-
The architecture I had in mind still has you effectively rate-limiting, simply by not doing anything at all with incoming updates beyond writing them to the scoreboard.
Assuming this stuff is all webby, then the actual I/O and processing load on client and server is pretty much the same for any given transaction - whether that's a client issuing a GET and receiving a fat response or a server doing a POST with a fat payload and receiving a client status code.
So the only real difference is how much useless traffic occurs as a result of client requests when there's been no change in the scores vs. server updates that the client is not currently in the right state to need.
Obviously you have actual requirements and all I have is speculation, but given only what's been posted here so far, it didn't look like an instant slam dunk for a push architecture.
But whether you push scores periodically or the client pulls them as required, it still seems to me that what you're implementing is a scoreboard.
-
ThrottleTheInterns