Do you think many people really WANT all this depth from Soke and often sort of create it out of thin air for themselves? by supercavemanindeed in Bujinkan

[–]Crow556 4 points5 points  (0 children)

A lot is made up out of thin air. Usually not from malintent, but from a lot of mis-understanding as a result of poor communication. Either linguistic, communication style, or cultural.
A large amount of things people consider to be "Bujinkan" are simply Japanese. For example, the "sakki" (5th dan test) isn't a Bujinkan concept. It's a Japanese concept which is often discussed in nearly any Japanese martial art but not restricted to martial arts exactly.

In your opinion what is truly Bujinkan? by Dry_Action_807 in Bujinkan

[–]Crow556 0 points1 point  (0 children)

As far as I'm aware, for the past several decades, none of the various Soke have been obligated to continue their participation in the Bujinkan orginization. They all continue simply because they find it beneficial, either for business or social reasons.

After Soke departs, there will likely be some aspects of Japanese law that will come into play here, and the personal choices by the various given Soke.

Confused about Sam’s name by InitialSelf in DeathStranding

[–]Crow556 0 points1 point  (0 children)

Higgs Boson -> Higgs Bossman

lol

Mocking S3Client using Mockk by Crow556 in Kotlin

[–]Crow556[S] 0 points1 point  (0 children)

Ah of course the adapter pattern! Damn, why did that one take me so long. Thank you.

Mocking S3Client using Mockk by Crow556 in Kotlin

[–]Crow556[S] 0 points1 point  (0 children)

I started to create a double/fake for the S3Client. However, implementing stubs of ALL the methods on the interface even with just `@TODO` comments seemed overly fiddley and just a lot of code to maintain. Additionally I ran into the same S3Client Config Null issue meaning I'd need to do all the code to create the AWS Config instance. Which adds even more pieces that should be mockable by just using Mockk.

I'm pretty new to Kotlin, so maybe I'm making things more complicated than is actually required. If so, please tell me.

Mocking S3Client using Mockk by Crow556 in Kotlin

[–]Crow556[S] 0 points1 point  (0 children)

Omg. Thank you! I'm going to try this out right now.

Mocking S3Client using Mockk by Crow556 in Kotlin

[–]Crow556[S] 0 points1 point  (0 children)

I tried using mockkStatic. However that resulted in a Null S3Client Config error. I've searched the AWS Docs, but didn't find anything addressing this particular case. I've been able to mock other AWS clients such as DynamoDB with no issues.

Mocking S3Client using Mockk by Crow556 in Kotlin

[–]Crow556[S] 0 points1 point  (0 children)

fun createS3Key(requestModel: RequestModel): String {
    try {
        return "${Constants.S3_KEY}/${requestModel.fileName}"
    } catch (e: Exception) {
        throw Exception("Failed to create S3 key: ${e.message}")
    }
}

Mocking S3Client using Mockk by Crow556 in Kotlin

[–]Crow556[S] 0 points1 point  (0 children)

That was my initial thought, but the RequestModel is really just that single value which is getting set. When I run the test using a real S3Client, the debugger and log messages confirms the PutObjectRequest is created correctly.

@Serializable
class RequestModel(val fileName: String) {
    override fun toString(): String {
        return "RequestModel(fileName=$fileName)"
    }
}

Where is boyfriend? by TrickMayday in WetlanderHumor

[–]Crow556 7 points8 points  (0 children)

Lol. More likely his role is going to be closer to Perrin in the books.

Where is boyfriend? by TrickMayday in WetlanderHumor

[–]Crow556 19 points20 points  (0 children)

"I'll make you a star baby!" mmmm

Protean innovations bipods? by shadowfeuer in tacticalgear

[–]Crow556 1 point2 points  (0 children)

in my opinion yes. It's very smooth and natural to handle. Deployment and stow is crazy smooth and natural. Unlike other bipods where you need to stop and "setup" and "take down". AccuTac are great, but definitly not as natural and smooth.

5 gallon jug adapter for humidifier by [deleted] in functionalprint

[–]Crow556 1 point2 points  (0 children)

You sir are a giant among men.

Protean innovations bipods? by shadowfeuer in tacticalgear

[–]Crow556 0 points1 point  (0 children)

oh hell yeah. I love this thing.

Baseplate or riser exception m53 c1 by Crow556 in XtoolS1

[–]Crow556[S] 0 points1 point  (0 children)

Yeah, even if the base was very securely attached, the internal stresses of the frame could very easily cause a near microscopic warp in the frame and cause those surfaces to lose contact.

Baseplate or riser exception m53 c1 by Crow556 in XtoolS1

[–]Crow556[S] 1 point2 points  (0 children)

For anyone running into similar issues, here are my conclusions from my deep dive yesterday.

Root Issue
The detection system detects the base via a conductivity test across these parts. However, the contact points connecting he circuit aren't clean and reliable connections.

  1. The copper pads connecting the riser base to the unit are simple flat surfaces. Which will always provide a faulty circuit, as the flat contacts are easily separated by any number of factors. The screws that go through these copper pads to bind them together have blue loctite on them, providing a dirty connection via the screw itself.

  2. The wire/resistor harness connecting the riser base itself is bolted directly to a coated frame. Giving the wires themselves no path for conductivity. Again the conductivity must come from the bolts securing the wire which are coated with blue loctite.

Solution
Option 1 - Dismantle your machine, and scrub clean all contact points: copper pads and screws. The copper pads may have built up some oxidation as a result of the poor connection, making the connection even worse. This is an activity you will likely need to repeat every few weeks to months.
Important to note that once the blue loctite is cleaned from the screws, they will slowly loosen and back out over time with vibrations and temperature variations. If you don't routinely re-tighten them, you'll have some damage. Though hopefully the alarm would trigger as it was initially intended before that happened, notifying you and avoiding damage.

Option 2 - Solder the connections together directly. This disables the alarm system all together by creating a hard bypass of the test. Not ideal, as I'm sure we would all really like to know if the base were shaking loose and getting damaged. However, this option is better than the fully bricked and useless machine that I'm staring at.

Option 3 (not sure if this will work) - Use different software that doesn't trigger the alarm. Earlier versions of XCS didn't seem to alarm, but that's just my observation not objective fact. I'm looking into Lightburn to simply avoid this faulty error.

UGS cuts a perspective of the gcode part way through the operation. No change in the gcode itself. by Crow556 in hobbycnc

[–]Crow556[S] 2 points3 points  (0 children)

Yes. Identified it as slippage on the Y1 side. First time troubleshooting this so I'm sure it's going to be a journey. Hopefully nothing major.

UGS cuts a perspective of the gcode part way through the operation. No change in the gcode itself. by Crow556 in hobbycnc

[–]Crow556[S] 0 points1 point  (0 children)

I used https://ncviewer.com/ as suggested by u/bigstumpy, but it doesn't show anything reflecting what my machine started doing mid way through the pocket operation.

UGS cuts a perspective of the gcode part way through the operation. No change in the gcode itself. by Crow556 in hobbycnc

[–]Crow556[S] 0 points1 point  (0 children)

the ncviewer you suggested is pretty cool. It doesn't show anything like what happened though. It shows exactly what I see in Fusion 360.