In the Java-verse it’s also do-able with Guice. I’ve tried it with Dagger but bailed (square peg / round hole).
I think I prefer Springboot AOP, especially with SpEL.
The term “cross cutting concerns” is thrown around a lot when discussing AOP. Took me a while to appreciate just how powerful it is in this context - sprinkle an AOP annotation here or there to avoid massive refactors in a large codebase, or avoid rewriting classes in a way that makes your classes themselves “cross cut concerns.”
Sonarqube or CodeQL reports might tell me what percentage of a repo is duplicated code, and a large percentage of that is in src/test/java
I find that a lot of the time this is not just some flippant observation but a clue that I should be using a mechanism like @ParameterizedTest instead of @Test, so I rewrite those tests in a way that makes them easier to set-up, define parameters/constraints, inputs, and outputs. Sometimes it does get a little convoluted as you either use a lot of naked Arguments.of() or define test-class-scoped nested records to encapsulate test parameters, inputs, expected outputs, etc.
Do you need the 15V input to torch the capacitors and run the relays?
Could I use a 5V USB ESP32 dev board instead, and just put a boost circuit or MOSFET on the relay load side for the explosion circuit when it needs to go off, or are there other components that need the higher voltage?
I feel like the importance of padding is a bit understated on this page - BLAS and LAPACK require LDA and LDB parameters, and you can definitely tune these to the page size of a particular system/machine to improve performance.
When working with BLAS/LAPACK or other matrix libs, you can often apply a little linear algebra to reshape the problem rather than the input data to avoid a transpose altogether
I’ve been skimming the source code and it looks promising for the stated use case. Wondering how to configure and set it up for a producer/consumer scenario where the producer puts compressed bytes on the wire and the consumer processes it; I can definitely see a use case where an edge sensor pumps compressed data to a cloud server with a GPU, though I don’t usually pipe doubles to a GPU.
Something worth thinking about that since you mentioned it’s geared towards “scientific” data streams. If we’re talking about precise measurements from instruments, your sensor is typically an analog signal which you digitize. Digitizers exist that can output floats, but DACs used in industry like a Rincon or Alazar (that sample at multiples of 100 MHz) prefer to output quantized shorts or ints that are rescaled to a float with a magic number (i.e. 32767/pi for a phase measurement, or gain/(16 mA) for industrial transducers) somewhere down the line. I bring this up because you pointed out your max throughput is about 120 MiB/s which would make it a big bottleneck for scientific data coming out of a digitizer that can pump out 800-1600MiB/s. 120 MiB/s throughput of doubles is not really that high for CPU level computations or network Tx bandwidth on modern hardware.
I recently finished reading “The Smartest Guys in The Room.” This definitely rhymes with some of the “energy efficiency” shenanigans committed by Enron’s EES subsidiary.
If you decide to pivot based on the comments in this thread about this turning into UberDrugz, an underserved market adjacent to this space is LTL freight.
For an example of this look for items on eBay whose shipping method is “freight.” As a buyer (or sometimes seller, if your buyer is clueless) of one of those items, it is your responsibility to arrange an LTL freight carrier (flatbed or liftgate truck). Fastenal and Uber freight will accept 1 pallet, up to a certain weight limit; you may even be responsible to bring it to a freight hub yourself. Above that size you’re on your own calling trucking companies, and renting a forklift or crane when you actually find a trucker.
It’s a smaller market than small packages, but more revenue per transaction. And if you figure it out and get it up and running, eBay (e.g.) might allow buyers and sellers to automatically select your service as the shipping method instead of black box “freight.”
Source = my personal experience 1. selling a metal building kit on eBay that the local zoning board would not let me erect. 2. Buying a large greenhouse kit online
mAh has always seemed silly to me as well. I get that the actual voltage of a battery is a function of battery charge %, load current, temperature and “other stuff”, but the battery designer/manufacturer knows all this… Why not just tell us how much energy is in it {,k,M}Wh or {,k,M}J?
It seems like it’s quite HTTP-centric (like most of the web…). I didn’t see anything on the page about this - can it also intercept / “reverse engineer” service calls that go over gRPC or WebSocket? I’m guessing at least a partial “yes” if the gRPC traffic uses grpc-web/Envoy?
Seems like a great product, potentially quite powerful for automated testing of SPAs.
I’m trying to wrap my head around the use case this was created for. If a python service dumps a numpy array to bytes and sends that as a payload to a C++ service, is that blob of bytes not interpretable by C++ as e.g. a struct with some size fields and a pointer to the start of the array? (Cutting out the filesystem/npy file)
Maybe I’m overthinking it but I can’t quite envision a use case where a python service and C++ service would be sharing a filesystem
I am curious, did you check how much your benchmarks moved (time and errors) if at all if you told the compiler to use —-use_fast_math or -ffast-math?
There’s generally not a faster version of inverse trig functions to inline, but it might optimize some other stuff out.
Unrelated to that, I’ve seen implementations (ie julia/base/special/trig) that use a “rational approximation” to asin, did you go down that road at any point?
I think I prefer Springboot AOP, especially with SpEL.
The term “cross cutting concerns” is thrown around a lot when discussing AOP. Took me a while to appreciate just how powerful it is in this context - sprinkle an AOP annotation here or there to avoid massive refactors in a large codebase, or avoid rewriting classes in a way that makes your classes themselves “cross cut concerns.”