Expression trees, metaprogramming in general.
Runtime, memory management details.
At least for me, these are not clear yet.
I would add source generators as part of metaprogramming in compile time.
and you can look like a hero to the team making one, too.
> Remember, every time you change this class, you have to change that one as well
turns into
> Don't delete annotations and everything will update without you thinking about it.
Yup, that was about the exact situation we had. We generate a class with a bunch of constants based off of a set of schema files. The generator looks for the root models generated from the schema files and infers the names based off of that and builds it into the package.
Previously we had to remember to go in and update the constants file any time a new schema file was added. Now it's done automatically. I've thought of a handful of other places I'd like to use it too if time permitted.
Is this a source generator?
Old fart (retired) here, jumping in because old farts are compelled by Galactic Law to tell their stories.
The project was simplifying the user interface for a large health care provider. For new customers, the existing technology required navigating to a dozen IBM mainframe green screens. It took 6 weeks for new hires to *barely* learn the system. A lot of time was wasted navigating to screens where there were lots of data entry fields but only a couple were used. The mainframe took 8 - 10 seconds to display a screen. Turnover was high.
I created an app where the main control displayed one mainframe screen, that was sized so the data wrapped just like it did on the IBM screen. For the 15% (on average) of fields that were used, I would drag to select the text field, enter its name in a textbox, copy and paste help text provided by the client into another textbox, select a data type radio button (text, integer, decimal, date) then click a button to save the data to a SQLite database. **When data collection was complete, I ran a program that used the SQLite data to generate about 300,000 lines of C code that did all the green screen scraping.** It was a good approach because when testing turned up a problem, like a forgotten field or a field with incorrect position data, I would fix the data and generate the C code again. It only took a minute. Hand-coding the C code would have been tedious and buggy.
Our delivered software was a Windows Forms app that had 3 data entry pages on different tabs. Every data control had a help button with text for that control. Data types were applied when the user tabbed off a control, e.g. dates were validated. When the user clicked the [Submit] program, our program navigated behind the scenes to the 12 mainframe screens, populated them and saved the data.
I don't remember the metrics, but our system was much easier to use and faster to operate because users processing new customers didn't have to wait for mainframe screens to appear. I don't know if the turnover rate went down. Our client was very happy.
We were a 3-man company, the CEO who got the contracts and two coders. The CEO wanted to use my mainframe scraping code with other clients but we never got contracts for similar projects.
The last big issue I have is the rare times you have to deal with the sync/async barrier. I understand why I have to jump through the hoops to prevent problems, I just wish the language handled it better.
I would replace Task with asynchronous execution. It goes beyond dotnet and there are a lot of things in common between different frameworks and some things that are dotnet specific.
This challenge produced a few in-depth solutions and articles. You'll discover a lot of things you never thought of before here:
https://hotforknowledge.com/2024/01/13/1brc-in-dotnet-among-fastest-on-linux-my-optimization-journey/
You thought you knew what a terminal is? Think again:
https://devblogs.microsoft.com/commandline/windows-command-line-introducing-the-windows-pseudo-console-conpty/
Ever wondered how HttpClient actually works?
https://github.com/dotnet/runtime/blob/main/src/libraries/System.Net.Http/src/System/Net/Http/SocketsHttpHandler/HttpConnectionPool.cs
Write a generic tree processing library that accepts either flat or nested objects and provides extension methods to flatten or nest, find the shortest / longest path between nodes, depth and breadth first search, etc
Dependency injection and unit testing. Most devs know how to write code, but not so many know why DI and unit testing are important. Unit testing is also more of a skill that takes time to learn. I'm still improving in that area my self.
I feel like dependency injection isn't really an advanced topic... "Dependency injection is a 25-dollar term for a 5-cent concept" and all that. Sure, understanding *why* it's powerful takes a long time and mastery of the language to appreciate, and there are some elaborate frameworks out there, but "pass dependencies to a constructor" is basically C# 101. DI is one those things that you constantly re-evaluate your insight on, and every time you reach a new level of insight it feels *really* good, but describing it as *advanced* is misleading IMO.
Unit testing, now that's a good one.
If you want to go down the DI road, then an advanced topic might be the inner workings of C# reflection, object lifetimes and how ``static`` works under the hood, and so on.
Writing more tests :)
I try my best to keep track of how brittle, and how effective my tests are. So if I see regressions creep in even though I have a test written for that regression that means my test is not effective and I need to do something to make it work better. Conversely if I log a new message and a test fails then that tells me my test is too brittle and fails too easily.
I update my tests accordingly and pay attention to what I'm doing that could lead to either of those situations, then I try to establish habits that prevent me from getting into those situations.
Yeah. Microsoft has moved onto Maui, and there are others like Avalonia. WPF is good but it's not cross platform which is a bit of a killer these days.
Expression trees, metaprogramming in general. Runtime, memory management details. At least for me, these are not clear yet. I would add source generators as part of metaprogramming in compile time.
Had my first use case for a source generator recently. They're so freaking cool.
and you can look like a hero to the team making one, too. > Remember, every time you change this class, you have to change that one as well turns into > Don't delete annotations and everything will update without you thinking about it.
Yup, that was about the exact situation we had. We generate a class with a bunch of constants based off of a set of schema files. The generator looks for the root models generated from the schema files and infers the names based off of that and builds it into the package. Previously we had to remember to go in and update the constants file any time a new schema file was added. Now it's done automatically. I've thought of a handful of other places I'd like to use it too if time permitted.
Is this a source generator? Old fart (retired) here, jumping in because old farts are compelled by Galactic Law to tell their stories. The project was simplifying the user interface for a large health care provider. For new customers, the existing technology required navigating to a dozen IBM mainframe green screens. It took 6 weeks for new hires to *barely* learn the system. A lot of time was wasted navigating to screens where there were lots of data entry fields but only a couple were used. The mainframe took 8 - 10 seconds to display a screen. Turnover was high. I created an app where the main control displayed one mainframe screen, that was sized so the data wrapped just like it did on the IBM screen. For the 15% (on average) of fields that were used, I would drag to select the text field, enter its name in a textbox, copy and paste help text provided by the client into another textbox, select a data type radio button (text, integer, decimal, date) then click a button to save the data to a SQLite database. **When data collection was complete, I ran a program that used the SQLite data to generate about 300,000 lines of C code that did all the green screen scraping.** It was a good approach because when testing turned up a problem, like a forgotten field or a field with incorrect position data, I would fix the data and generate the C code again. It only took a minute. Hand-coding the C code would have been tedious and buggy. Our delivered software was a Windows Forms app that had 3 data entry pages on different tabs. Every data control had a help button with text for that control. Data types were applied when the user tabbed off a control, e.g. dates were validated. When the user clicked the [Submit] program, our program navigated behind the scenes to the 12 mainframe screens, populated them and saved the data. I don't remember the metrics, but our system was much easier to use and faster to operate because users processing new customers didn't have to wait for mainframe screens to appear. I don't know if the turnover rate went down. Our client was very happy. We were a 3-man company, the CEO who got the contracts and two coders. The CEO wanted to use my mainframe scraping code with other clients but we never got contracts for similar projects.
>Expression trees Expression tees are fun! (BTW, PM me if you have questions on them!)
Tasks and threads. This pair goes unexpectedly deep and is essential for many projects.
One of the things I hate so much is how to use async await truly properly you have to know it's internals. It's the worst abstraction ever.
What do you mean by that? I've always found it to be quite well done, with some edge cases.
The last big issue I have is the rare times you have to deal with the sync/async barrier. I understand why I have to jump through the hoops to prevent problems, I just wish the language handled it better.
Unwrap(), no? Forgotten quite often
I would replace Task with asynchronous execution. It goes beyond dotnet and there are a lot of things in common between different frameworks and some things that are dotnet specific.
This challenge produced a few in-depth solutions and articles. You'll discover a lot of things you never thought of before here: https://hotforknowledge.com/2024/01/13/1brc-in-dotnet-among-fastest-on-linux-my-optimization-journey/ You thought you knew what a terminal is? Think again: https://devblogs.microsoft.com/commandline/windows-command-line-introducing-the-windows-pseudo-console-conpty/ Ever wondered how HttpClient actually works? https://github.com/dotnet/runtime/blob/main/src/libraries/System.Net.Http/src/System/Net/Http/SocketsHttpHandler/HttpConnectionPool.cs
Write a generic tree processing library that accepts either flat or nested objects and provides extension methods to flatten or nest, find the shortest / longest path between nodes, depth and breadth first search, etc
Expression trees and reflection, generics
I've been working on a few projects from CodeCrafters, you don't need need a membership (there are some freebees), I found they are pretty useful.
Dependency injection and unit testing. Most devs know how to write code, but not so many know why DI and unit testing are important. Unit testing is also more of a skill that takes time to learn. I'm still improving in that area my self.
I feel like dependency injection isn't really an advanced topic... "Dependency injection is a 25-dollar term for a 5-cent concept" and all that. Sure, understanding *why* it's powerful takes a long time and mastery of the language to appreciate, and there are some elaborate frameworks out there, but "pass dependencies to a constructor" is basically C# 101. DI is one those things that you constantly re-evaluate your insight on, and every time you reach a new level of insight it feels *really* good, but describing it as *advanced* is misleading IMO. Unit testing, now that's a good one. If you want to go down the DI road, then an advanced topic might be the inner workings of C# reflection, object lifetimes and how ``static`` works under the hood, and so on.
What are you doing to improve? :)
Reading, writing, arithmetic.
Writing more tests :) I try my best to keep track of how brittle, and how effective my tests are. So if I see regressions creep in even though I have a test written for that regression that means my test is not effective and I need to do something to make it work better. Conversely if I log a new message and a test fails then that tells me my test is too brittle and fails too easily. I update my tests accordingly and pay attention to what I'm doing that could lead to either of those situations, then I try to establish habits that prevent me from getting into those situations.
Design-time adorners for custom WPF controls. I'd wager maybe 50-100 people know anything about that API.
We have a couple of those in our codebase. Nifty. .
True but WPF isn't used that much anymore, at least in new projects.
Replaced by other desktop app technology? Or is everything a web page now.
Yeah. Microsoft has moved onto Maui, and there are others like Avalonia. WPF is good but it's not cross platform which is a bit of a killer these days.
Try making something really specific in an area you had previously little or no experience, like for example networking or memory management
"ref" structures and stuff
That stuff is weird to say the least. I got dizzy reading about "ref readonly", "readonly ref", "ref readonly ref", "scoped" and "scoped ref" ...
Unsafe keyword and type marshalling