|
tef posted:ed is the standard editor ?
|
# ? Aug 8, 2017 18:25 |
|
|
# ? Jun 5, 2024 07:35 |
MALE SHOEGAZE posted:i use mongo booster and it sucks but not as much as mongo compass which is lol my coworkers seem to use that as well, but i wont touch it seeing the free version limitations, unless someone spills the beans on that
|
|
# ? Aug 8, 2017 18:32 |
|
tef posted:ed is the standard editor ed is the standard editor is the standard editor joke
|
# ? Aug 8, 2017 18:59 |
|
i'm trying to figure out/understand message queue platforms (like activemq) to see if it would be applicable to this server/client-monitor thing i've wanted to do for work for a while is there a difference between a topic and a queue or are they semantically the same thing (ed) i'm having the damnedest time finding any activemq "hello world"s for C# and C++, work proxy is being a cast iron bitch today Ciaphas fucked around with this message at 19:53 on Aug 8, 2017 |
# ? Aug 8, 2017 19:48 |
|
hahaha omg I lovelovelove inheritance "Just inherit this super type and your library will be super simple" But what about all these abstract methods I don't need? 95% of the class is going to throw NotImplementedExcpetion. "lmao so what it'll handle all the backend connection stuff so you can DRY" But this super type is highly opinionated about its dependencies and I don't actually need 90% of them anyway. BTW, this is why I prefer composition over inheritance. *spit takes* "But inheritance is one of the pillars!!!" This is making me actually hate oop and I never thought that would happen.
|
# ? Aug 8, 2017 21:11 |
|
inheritance is generally considered to have been a mistake tef thinks message queues are bad. idk i guess i agree but it's not something i've ever had the pleasure of dealing with intimately.
|
# ? Aug 8, 2017 21:36 |
|
having only experienced the terms from the implementer side I believe a queue holds messages until any one consumer consumes it, while a topic sends each message to all consumers that are subscribed to it. the difference being whether one or all consumers get each message.
|
# ? Aug 8, 2017 21:41 |
|
good luck implementing exactly-once semantics in any meaningful way though
|
# ? Aug 8, 2017 23:45 |
|
terrible programmer status: I just spent 3 hours trying to figure out why ProDOS 2.4.1 crashes on my Apple II emulator ProDOS 2.4 has hacked-in support for NMOS CPUs, which it detects using an illegal opcode that decodes to INC on a 65C02 and a NOP on a 6502. my CPU emulator printed an error and reset if it encountered an illegal instruction. I added the illegal NOPs to my instruction decoder and now it works lol well "works" in that it says REQUIRES 64K since I don't emulate any bankswitched memory cards
|
# ? Aug 8, 2017 23:46 |
|
Luigi Thirty posted:terrible programmer status: I just spent 3 hours trying to figure out why ProDOS 2.4.1 crashes on my Apple II emulator aw, you don't emulate a 65C02 or the common behaviors of unused opposes? also: yet you don't emulate any bank switched memory cards yet
|
# ? Aug 8, 2017 23:50 |
|
Jabor posted:good luck implementing exactly-once semantics in any meaningful way though i'm just going off of http://activemq.apache.org/how-does-a-queue-compare-to-a-topic.html
|
# ? Aug 8, 2017 23:52 |
|
inheritance isn't a mistake, its just almost always horribly used like there are cases of horrible poo poo within the java standard library
|
# ? Aug 8, 2017 23:53 |
|
inherit this *points to methodz*
|
# ? Aug 9, 2017 00:16 |
|
Sapozhnik posted:inheritance is generally considered to have been a mistake currently loving hate message queues.
|
# ? Aug 9, 2017 00:17 |
|
message queues should only be used when you have zero control over the producers (or you give zero fucks about the consumer). if you're inserting a message queue between your own producer and consumers you are a top tier scrublord
|
# ? Aug 9, 2017 00:23 |
|
the talent deficit posted:message queues should only be used when you have zero control over the producers (or you give zero fucks about the consumer). if you're inserting a message queue between your own producer and consumers you are a top tier scrublord I'm still trying to figure out a way to say this to coworkers without sounding too belligerent.
|
# ? Aug 9, 2017 00:28 |
|
eschaton posted:aw, you don't emulate a 65C02 or the common behaviors of unused opposes? i will add 65C02 when i add Apple IIe support i have a LanguageCard class but the softswitches for bankswitching memory aren't hooked up yet
|
# ? Aug 9, 2017 00:29 |
|
the talent deficit posted:message queues should only be used when you have zero control over the producers (or you give zero fucks about the consumer). if you're inserting a message queue between your own producer and consumers you are a top tier scrublord speaking as a top tier scrublord what's the alternative if you control (indeed, are writing) both the producer and consumer i first tried direct sockets and that works but i have been told it is a major no no
|
# ? Aug 9, 2017 00:34 |
|
did you read that thing tef wrote a few weeks ago
|
# ? Aug 9, 2017 00:41 |
|
MALE SHOEGAZE posted:currently loving hate message queues. at my startup our architecture is microservices and a message queue. each microservice has its own mongo database, because this reduces coupling. allowing the services to access the same database would increase coupling, so if one service needs access to data in another service, the originating service will just dump the entire collection into the pipeline, and the consuming service will write out all of the entries into its own database. whenever an entity in the database is updated, the responsible service will emit an update event, and dump the entire object into the pipeline. consuming services will then write it to their own db, taking extreme care to update any and all data associations (a traditional DB would of course enforce these relationships for you, but it's no loss because keeping data in sync is a totally trivial problem compared to coupling, which is the worst problem). the architects of this system did not concern themselves with concurrency, because data races are trivial compared to coupling. we've simply forced each consumer to run on a single thread, because concurrency issues are difficult to solve and we have more important problems such as reducing the amount of coupling in our system. naturally, this system contains json entities that can be over 1mb compressed. if a user updates a single field on one of these entities, the entire 1mb model will get dumped into the queue. if they update the model twice (or 100 times) it will get dumped into the queue each time. this in no way overwhelms the system. a few months back, i introduced an RPC mechanism so that we could at least make synchronous calls between services in response to user events. today my lead informed me that we're going to deprecate the RPC system because it increases coupling. this is how you architect a system with 12 microservices that cannot handle more than 4 or 5 concurrent users before falling over. Fortunately, since everything is so decoupled, the system at least maintains the appearance of working. DONT THREAD ON ME fucked around with this message at 00:47 on Aug 9, 2017 |
# ? Aug 9, 2017 00:44 |
|
holy
|
# ? Aug 9, 2017 00:51 |
|
MALE SHOEGAZE posted:a few months back, i introduced an RPC mechanism so that we could at least make synchronous calls between services in response to user events. today my lead informed me that we're going to deprecate the RPC system because it increases coupling. this was my favorite part btw
|
# ? Aug 9, 2017 00:51 |
|
Ciaphas posted:speaking as a top tier scrublord what's the alternative if you control (indeed, are writing) both the producer and consumer is direct sockets a terrible idea on loop back?
|
# ? Aug 9, 2017 00:53 |
|
MALE SHOEGAZE posted:at my startup our architecture is microservices and a message queue. a pro post
|
# ? Aug 9, 2017 00:59 |
|
MALE SHOEGAZE posted:at my startup our architecture is microservices and a message queue. lol. p-langs.
|
# ? Aug 9, 2017 01:02 |
|
MALE SHOEGAZE posted:at my startup our architecture is microservices and a message queue.
|
# ? Aug 9, 2017 01:03 |
|
it's insane. our services are divided up based on their business domain, not on their functionality. like: it makes sense to me to have a document service that deals with storing and converting and retrieving documents. it makes sense to have a service that deals with collecting metrics. splitting based on business domain just means that we have a) tons of shared data that needs to be kept in sync between services and b) can't we just enforce these separations on the code level instead of on the architecture level?
|
# ? Aug 9, 2017 01:06 |
|
"We don't want tires on this new car, because tires go flat. Instead, we will develop a complex system of carbon-fiber centipede legs."
|
# ? Aug 9, 2017 01:14 |
|
hobbesmaster posted:is direct sockets a terrible idea on loop back? well the clients are windows machines and the process server is a linux box, sorry, i didn't mean they were both on the same machine
|
# ? Aug 9, 2017 01:20 |
|
MALE SHOEGAZE posted:at my startup our architecture is microservices and a message queue. bet you things are 'reusable' too
|
# ? Aug 9, 2017 01:21 |
|
well, tef is right there but let's see if i understood him correctly.Ciaphas posted:speaking as a top tier scrublord what's the alternative if you control (indeed, are writing) both the producer and consumer everything ultimately runs over direct sockets, what you're saying is you rolled your own serialization and/or framing protocol. don't do that. pick a serialization and framing format and make the producer talk directly to the consumer(s). grpc works, probably. it's just protobufs over http2. have a static config file somewhere with the urls of the things that need to get notified when things happen. the exact details depend on the exact nature of your problem.
|
# ? Aug 9, 2017 01:48 |
|
Sapozhnik posted:well, tef is right there but let's see if i understood him correctly. ah didn't realize Lutha Mathin was talking to me otherwise 'id have gone looking for the posts thanks for the info, grpc gives me much more to look at and learn
|
# ? Aug 9, 2017 02:36 |
|
Ciaphas posted:speaking as a top tier scrublord what's the alternative if you control (indeed, are writing) both the producer and consumer no-one ever got fired for using grpc
|
# ? Aug 9, 2017 02:55 |
|
Ciaphas posted:speaking as a top tier scrublord what's the alternative if you control (indeed, are writing) both the producer and consumer it literally depends on the protocol the talent deficit posted:message queues should only be used when you have zero control over the producers (or you give zero fucks about the consumer). if you're inserting a message queue between your own producer and consumers you are a top tier scrublord aka 'pubsub is about isolating, not integrating' sure i wrote something about this in this thread already
|
# ? Aug 9, 2017 03:01 |
|
"google uses grpc, it has to be great" *ignores the tons of middleware and discipline google engineers have to make it work* grpc is probably fine. I'm just tired of RPC (the sixteenth big son) and "google does it so should we".
|
# ? Aug 9, 2017 03:07 |
|
grpc is a garbage implementation of an ok idea istrio or finagle is what you actually want
|
# ? Aug 9, 2017 03:22 |
|
i mean rpc is just a catch-all term for any protocol where one party sends requests for which the other party always generates one response. it's too general a concept to be either good or bad in its own right. rpc with some sort of stateful context to the conversation is bad (see: corba, dcom, etc). whatever crazy conway's law bullshit shoegaze's company has going on is bad.
|
# ? Aug 9, 2017 03:29 |
|
MALE SHOEGAZE posted:at my startup our architecture is microservices and a message queue. wow... and I thought I had it bad...
|
# ? Aug 9, 2017 06:18 |
|
Sapozhnik posted:i mean rpc is just a catch-all term for any protocol where one party sends requests for which the other party always generates one response. it's too general a concept to be either good or bad in its own right. i dunno sometimes stateful contexts can work if you're using like a session id to represent it, like within a cookie
|
# ? Aug 9, 2017 07:33 |
|
|
# ? Jun 5, 2024 07:35 |
|
MALE SHOEGAZE posted:at my startup our architecture is microservices and a message queue. needs more containers and to be ported to kubernetes by next month tia
|
# ? Aug 9, 2017 07:34 |