The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
Why would anyone have that and why would anyone think that's a good idea?
Your manager must be the anti-productivity.
A daily stand-up shouldn't take more than 15 minutes and I already think that's too long.
Have you tried just flat-out say it?
"Guys, I don't know what I'm doing here so I'm getting back to actually getting things done."
I've done it in the past with mixed results (although the meetings always got shorter)
I didn't exaggerate.
Chances are, more people are annoyed by this, but no one wants to speak up.
Monday, before the meeting, say something like "can we keep this REALLY short because I think our regular 45 minutes are WAY too long."
Also, 12 people sounds like a lot, are you sure they all need to be there?
If not, you can say so, "I think it doesn't make sense I'm here with x and y because I don't even work with them" or something like that.
45 minutes is still too long, and with everyone getting coffee before and after, the productivity loss is still an hour.
Get some meeting bingo cards and distribute them to other folks on the meeting. I did this once and called out Bingo in a meeting. The look on the VPs face was priceless when I explained that I had a buzzword bingo card and he just hit not one, but two rows.
It least we both now realize we're not alone in this experience - except I not only don't have them every day, but on the off chance I do get invited I'm generally "overlooked" for subsequent meetings on the subject. The "penalty" for asking questions.
Oh - you reminded me I have a telephone in meeting today. So much for benevolent forgetfulness. I'll get even with them (at least), shortly.
I have produced an article on a difficult topic - creating a Socket that can be awaited
I haven't used the task framework enough to explain all of it - just the things I've done before, but some of them have a lot of moving parts, and so are more difficult to explain.
What I'd like is if someone who has some experience with Socket and Task could review it. It's kind of cool code, so I'm not relying purely on your altruism here. Anyway, what I'm after is some feedback about how digestible it is.
If you're interested let me know and I'll link to it.
I really appreciate feedback, but I know most of you are busy with work.
I like this article. I haven't seen someone use awaitables like this before.
How the Completed event and OnCompleted callback interact is really not obvious, even from your description of what each individually does. I think the purpose of this setup is so that the continuation passed to OnCompleted will only be executed once the event completes. If Completed fires first, _continuation == _sentinel which triggers the Task.Run(continuation) in OnCompleted. If OnCompleted fires first, _continuation = continuation, so prev = continuation when prev() is executed.
I believe that this entire thing falls apart though if Reset() isn't called after each Completed/OnCompleted trip. If _continuation == continuation from an earlier call, OnCompleted falls through and the current continuation is lost, while Completed executes the previous continuation.
I really want to dive into this when it isn't 2am. I suspect OnCompleted is for completion of pre-await code which is why some of these hoops are needed. Otherwise the ordering of Completed and OnCompleted would be known.
I found two more articles if you wanted to check them out. I only did a cursory overview. It seems like they dive into things in a little more detail but it still wasn't obvious to me how the awaiter methods interact with the overall task architecture.
Found another good one. Also I couldn't sleep because I had to know the answer to this. Kinda funny how OnCompleted is only called if IsCompleted is false It blew my mind when I realized all of the SocketAwaitable code is just for Reset() so you avoid allocating a TaskCompletionSource on each Receive/Send call
Assuming it wasn't a joke, GetResult() isn't called CheckResult() because other awaiters may return a value like a Task<T>'s awaiter. This awaiter implementation doesn't have a return value since that value is returned via the SocketAsyncEventArgs instead.
Thanks for sparking a fun night of learning but now I'm actually off to bed
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
57, having big problem converting conventinal apps to browser apps.
Anyway still relaxed:
Smiles at the new technologies (browser apps). Something fails every week then and when because 'something' in the depths of the web frameworks (be it vue, stencil, react, whatever) has changed.
It does not solve my Problem, but it answers my question
Chemists have exactly one rule: there are only exceptions