This is disheartening: https://arstechnica.com/space/2025/07/trump-administration-moves-to-tighten-the-noose-around-nasa-science-missions/

@nblumhardt Look, #JetBrainsRider learned a new #OpenTelemetry trick and it works pretty well with #SeriLog
I wish there would be a similar @seq plugin for Rider that would just spin up a local dev Seq instance for me and sow the logs directly in the IDE.

https://github.com/bitbonk/OTELSerilogDemo

#dotnet #o11y #observability #dotnet

Hey, I thing we need to ask for some help w/ the forthcoming CritterWatch. Right now we need to have more sample applications that do some messaging. Does anyone have any suggestions for some example repositories out that there show microservices (or any services) communicating via async messaging? Doesn't have to be .NET, certainly doesn't need to be Wolverine. Just looking for problem domains and samples so I don't have to make up anything:-)

I'm a couple of episodes in on #Ironheart on #DisneyPlus and loving it. Dominique Thorne is great. I'm sure there are some die hard Marvel fans finding something to complain about, but I couldn't give a hoot.

TIL: "e.g." is not "exempli gratis", which I was translating as "free example", but "exempli gratia" which I am gathering is something more like "a good-will example". Health warning: I studied Latin for 6 weeks for half an hour a week. I remember nothing of it..

Hey #dotnet folks, if you're running in a cloud environment, be careful upgrading to the latest version of .NET 8.0.17 before double-checking your forward headers configuration and proxy settings. You may have a misconfigured app, but it's been working up to now.

Boost to let others know. Cheers.

https://duendesoftware.com/blog/20250624-dotnet-8017-upgrades-forwarded-headers-and-unknown-proxy-issues

#azure #aws #kubernetes

@wackJackle Where did you grab the screenshot from?

@mihamarkic Jolly good questions, and shows up that I hadn't thought that through! I'd guess the answer to both is `default(int)` , i.e. zero. But that does smell quite bad and I can see that as being a big reason to say no to my proposal. It'd be especially bad for non-nullable reference types where `nullable` was enabled, as they'd either end up with a null value at run time or the compiler would have to insist on only nullable reference types getting created between the `try` and `catch`. Okay, I take it all back. Terrible idea!!

@CriticalSilence Just for interest, the impetus for writing this proposal was that for the umpteenth time I found myself extracting the contents of one method into another so I could put a try...catch around the whole thing without indenting everything further. The context here is if *anything* goes wrong in the method, I need to stop the exception bubbling so I can return an explicit failure from the method and thereafter refund a payment. My default design position is top level exception handling, but there are some places where you do need different behaviour for resilience.

@CriticalSilence I see your points, but personally they don't bother me. On the first one, people can (and do) already use try-catch too much. I don't really think this makes it all that much easier to misuse, but it's subjective and we may have to disagree on that.

On the second point, I view it as similar to the `using` and `namespace` declarations versus their statement equivalents. I will concede that the difference here is that the scope of the application can be foreshortened by a `catch` or `finally`, where `using` and `namespace` declarations are until the end of the method of file respectively. We seem okay with these not having a statement block with indented code, so why should `try` be different?

That last point begs a rebuttal that you could start levelling the same arguments for `if`, `else` and probably other constructs that are followed by statement blocks, and that would clearly be absurd. But I still think `try` is different enough that this would be okay.

@mihamarkic It would be a `try` declaration rather than statement, so there's no enclosing statement block to limit the scope of the variables.
`try;`
`var x = 3;`
`catch (Exception e) => _logger.Debug(x);`
`Console.WriteLine(x);`
I don't think there's any IL reason why the variables would need to be scoped to inside a try block. The emitted IL would indicate that the set of instructions protected by the `try;` declaration would comprise everything from there to the `catch` (or `finally` or end of the method / statement block). That shouldn't have any bearing on variable scope. However, getting the variables into the lamda for the `catch` will still be via capture. The `Console.WriteLine(x)` in the example above should still execute fine even though outside of the set of statements protected by the `try;`. No need to declare an uninitialized or dummy variable value outside of the block:
`int x = Int32.MinValue;`
`try {`
`x = 3;`
`}`
`catch (Exception e) { _logger.Debug(x); }`
`Console.WriteLine(x);`

@CriticalSilence Top level exception handling basically is a massive try catch block,and a common pattern. I don't think what I am suggesting makes it easier to write try catches, but it stops make the code more less messy, I think.

I see there are various similar proposals, including the catch lambda. They're not exactly the same (see https://github.com/dotnet/csharplang/discussions/9293 and linked issues), but the criticism seems to be to do with nested try..catch considerations. Not sure if my proposal gets around that. I'll need to dig deeper. I feel like disallowing any more `try` keywords in the same method ought to resolve any issues, but I understand this might feel a bit hacky.

In #csharp #dotnet we now have the `using` declaration:
`using var connection = new SqlConnection(...);`
This stops us having to surround large blocks of code with a `using` statement block. I'd like to see something similar for `try...catch` . Maybe simply:
`try;`
`// Code that might throw, then at the end of the method...`
`catch (Exception e)`
`{`
` // handling code`
`}`
One advantage would be less indentation, but another might be ability to access variable from the statements after the `try` declaration but before the `catch`. Currently a common pattern is declaring a variable before the `try` block. If there are issues with variable scope, the compiler could capture in the same way a lambda would. Indeed, maybe the `catch` could be a declaration too:
`catch (Exception e) => { /* handling code */ };`
and we'd get the capture for free.

The internet has become one of the most important spaces for social interaction we have ever seen, and the debate about its impact on all aspects of society is urgent and pressing.

Our new report - The Social Internet - highlights an emerging crisis for the giant social platforms - toxic and polarised online environments, but enormous potential to transform our world in positive ways. Read and discuss:

https://www.bbc.co.uk/rd/articles/2025-06-social-media-change-issues-problems-report

#social #socialmedia #technology

@drahardja @init6 @bruces I'm doing the same. Legend.

*She's almost a one-woman Fourth Estate at this point

https://www.citationneeded.news/it-matters-i-care/

The abbreviation of "identity" as "ID" bugs me. "ID" is short for "Identity Document", and yet used throughout code as an abbreviation for "Identity". I don't think it'd be reasonable to say that an "ID" database column was a document in and of itself. If it has to be abbreviated, it should surely be "Id".

But I know I'm fighting a lost cause here.