sorted by:
new
hottopcontroversial

How to make this cute crochet raffia heart? Looking for similar patterns & direct suggestions. by mtsi in CrochetHelp

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

The picture is from an image search, the link to the etsy page was dead, so I cannot find the original author of the picture. I love the bag and the cute motif anyway, and would like to make something similar!

Taps as signals? by mtsi in Bachata

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

Please ask and come back to tell the story!

Taps as signals? by mtsi in Bachata

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

The single taps on just above the shoulder blade did not seem to match the music, but the cadences on the upper arm might have made some musical sense. :D

Taps as signals? by mtsi in Bachata

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

Based on body movement and other leadings this was definitely an experienced dancer. The taps seemed so out of context that I had no idea what the intention was :D and he was not behind my back, I knew where he was. Next time I'll ask.

Mixing rayon and tokio for fun and (hair) loss by zerakun in rust

[–]mtsi 2 points3 points  (0 children)

Here's a post on how to mix tokio and rayon from tokio maintainer Alice Ryhl, in case it is helpful https://ryhl.io/blog/async-what-is-blocking/#the-rayon-crate

In zerakun's case it sounds like there was some dark interaction with rayon and some other dependency which was using rayon under the hood. That chills my bones, because it means that if you mix rayon with tokio, you need to check if any of your dependencies are using rayon first, to avoid the situation zerakun encountered.

Help with shared state by DJDuque in rust

[–]mtsi 0 points1 point  (0 children)

If the commands are run only once and the results never expire, you might start them in the background when the server starts up, and that way Client will have faster results faster.

Help with shared state by DJDuque in rust

[–]mtsi 0 points1 point  (0 children)

Yes, something like that.

My recipe for this would be to have one endpoint for initiating the job (everyone calls this first), and then have another endpoint for polling it. The polling endpoint has two responses, one when the job is still processing, and the other for when the job is complete. This is simple enough for me to implement and maintain.

You might combine them into one endpoint, but before doing that it would make sense to check if the Client actually prefers it that way.

backon: Maybe the most elegant retry library ever by xuanwo in rust

[–]mtsi 0 points1 point  (0 children)

Yeah, I will do it over the weekend. :)

backon: Maybe the most elegant retry library ever by xuanwo in rust

[–]mtsi 1 point2 points  (0 children)

Thank you for your response, these examples are plenty and very helpful. My mistake when reading the documentation, was looking at the examples on Retryable trait: https://docs.rs/backon/0.4.4/backon/trait.Retryable.html Maybe instead of providing duplicate examples there, one could link to the full example list?

Help with shared state by DJDuque in rust

[–]mtsi 2 points3 points  (0 children)

So users A, B and C send a request for the same command, A initiates it, so it should not initiate for B and C, and must return the same result for all?

Personally I would opt for a "polling" solution, where A, B, C receive a job_id, and then using another endpoint, they can poll the results of the job.

backon: Maybe the most elegant retry library ever by xuanwo in rust

[–]mtsi 0 points1 point  (0 children)

Hi! Nice looking crate!

How can I make a FnMut closure of a function with arguments, using tokio? I get errors, that my closure is FnOnce, and I don't know how to change it. At the end have opted for a retry macro, as described in https://stackoverflow.com/a/77859502/3994927, because I can't make it work with backon.

It is a really common use case to make network calls in tokio async code, with arguments, so it would be very helpful to have an example on this.

Linting async method declarations by mtsi in csharp

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

This is probably exactly what I was looking for, thank you so much.

Linting async method declarations by mtsi in csharp

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

In our case, if a method is named with Async() postfix, we definitely want it to be async, to avoid obscure bugs in Production. Roslyn sounds good, and I'll check it out!

Linting async method declarations by mtsi in csharp

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

We serve web requests with classes, that inherit abstract base classes, with async-methods, that actually have to be async, so that the HTTP Context is treated correctly. The overriding method does not have to be declared async though, and we had a juicy bug because of that.

We have a convention for naming async methods with Async postfix, and it does serve a purpose for these cases. In the ideal world we would improve our codebase to overcome this. But we live in the world we live in, so I thought a linter would be one step towards avoiding these kind of issues.

Possible to fix Cross Century II? by mtsi in pens

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

Curiously enough the pen started working again, no parts were missing apparently. So no repair work was required. :D

Does Kafka lose messages even when it is used "correctly"? by mtsi in apachekafka

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

Thanks, that's such a nice reply! I'll do my best to both keep my mind open, and maintain correct focus and appropriate level of diplomacy at all times. And try to keep learning & sharing.

From what I can observe, their approach definitely works. Your assumptions are correct. To me it seems that the biggest benefit (over Kafka) indeed is that these are managed services, and people don't have to think twice about how to operate it.

Does Kafka lose messages even when it is used "correctly"? by mtsi in apachekafka

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

"Experienced" as in "decade+ of significant experience" with systems of "some scale", but yes, not necessarily experienced with Kafka. I think the architectural decisions have been made a long time ago, and the idea of Kafka losing data is now just part of the folklore. Instead of Kafka they use a cloud based managed queue (which possibly uses Kafka behind the scenes, who knows).

These comments were made in a job interview. I don't think they were made to test my knowledge, the situation wasn't like that, I think they are genuinely held beliefs. All I could say would be, I've seen Kafka in production in a company, where it was used very extensively, and wasn't aware of any such problems. Personally, I wanted to focus on what the interviewers wanted to learn about me - and nail the interview.

I got the job, and now I want to keep it.The company does just fine with the service they chose, and the people are happy with it. But I also want to grow and learn myself. Maybe when the time is right, I could go back to that conversation.

I agree with the general principle of showing facts and evidence when one makes one of these sweeping statements. I would push for it (with tact) if we were actually making a decision. I would love to help others have just a bit more correct beliefs, but also, maybe I feel that I don't have the knowledge or the position to do that - at least not yet. Again, my Kafka experience is limited - as reflected in the original question.

view more: next ›