This is something I wrote for an application I’m developing. This is an implementation of INotifyPropertyChanged that requires no backing fields, just call Set(value) or Get(). Internally it uses a dictionary to store the state and even reuses ChangedEventArgs
Note to myself – Excellent article on the worker services in .NET Core 3:
Say you are developing an API where you have to use Thread.Sleep(…) since you are working with some device via a COM and you need to wait for the predefined amount of time before you can read from the device and there is no way around it. For example:
Rule in designing APIs in my head, is that you shouldn’t make something Async unless the underlying API(s) you are working with is also Async or uses BeginX EndX, continuations, i.e. something that is already asynchronous. By prematurely making something Async you are making an implementation decision for the consumer of the code. The code provided above doesn’t expose any such API.
Stumbled upon this article written by no other than Eric Lippert listing the top 10 design faults of C# language. Here is the summary, the source to the full article is at the bottom.
#10: The empty statement does nothing for me
Reflects on the fact that lone “;” is a legal statement
#9: Too much equality
There are too many ways check for equality: ==, Equals, ReferenceEquals, CompareTo(…).
From personal experience double.NaN == double.NaN is false but double.NaN.Equals(double.NaN) is true
#8: That operator is shifty
Weirdness around << and >> operators
#7: I’m a proud member of lambda lambda lambda
The way C# 2.0 implements anonymous delegates
#6: Bit twiddling entails parentheses
#5: Type first, ask questions later
C# borrows the “type first” pattern from C and many of its other successor languages – something I got used to and the “correct” way now seems illogical to me
#4: Flag me down
The fact that you can create invalid enum values and have to manually check for this in the code
#3: I rate plus-plus a minus-minus
++i, i++, i +=1 etc. how much confusion and the pain it caused.
#2 I want to destruct finalizers
Agree with the author that finilisers in C# are symptoms of a bug. Seen it way too many times myself.
#1 You can’t put a tiger in the goldfish tank, but you can try
“array covariance” and how this could lead to run-time exceptions.
C# 7 provides a very powerful feature from the performance standpoint. This feature is returning by ref. Essentially this allows for value types to be returned without having to copy them.
The guidelines are normally that you shouldn’t use a struct with too many fields. Various sources quote various size guidelines. Whenever the struct was over the prescribed size it was recommended that you pass it by reference.
With the new syntax for returning types by reference, it’s now more convenient (no more methods returning via out parameter) to use structs.
In performance critical scenarios where you need to avoid polluting managed heap with too many Gen #0 objects using structs has now become more natural. In the past dealing with structs was somewhat cumbersome if you dealt with a large number of fields and needed to avoid copying of values.
I have worked on a large application at McLaren – Telemetry Acquisition System that is supplied to all teams. The performance of the application is very critical as it has to process gigabytes of telemetry data. We have used structs extensively to squeeze out every bit of performance from .NET runtime.
I think it’s my second favourite feature after value tuples.
The Task Parallel Library (TPL) was introduced in the .NET Framework 4, providing core building blocks and algorithms for parallel computation and asynchrony. This work was centered around the System.Threading.Tasks.Task type, as well as on a few higher-level constructs. These higher-level constructs address a specific subset of common parallel patterns, e.g. Parallel.For/ForEach for delightfully parallel problems expressible as parallelized loops.
While a significant step forward in enabling developers to parallelize their applications, this work did not provide higher-level constructs necessary to tackle all parallel problems or to easily implement all parallel patterns. In particular, it did not focus on problems best expressed with agent-based models or those based on message-passing paradigms. These kinds of problems are quite prevalent in technical computing domains such as finance, biological sciences, oil & gas, and manufacturing.
For TPL Dataflow (TDF), we build upon the foundational layer provided in TPL in .NET 4. TDF is a complementary set of primitives to those primitives delivered in TPL in .NET 4, addressing additional scenarios beyond those directly and easily supported with the original APIs. TPL Dataflow utilizes tasks, concurrent collections, tuples, and other features introduced in .NET 4 to bring support for parallel dataflow-based programming into the .NET Framework. It also directly integrates with new language support for tasks and asynchrony provided by both C# and Visual Basic, and with existing language support in .NET 4 for tasks provided by F#.
Definitely something to play with when my brain has more oxygen (suffering from anaemia right now)
AForge.NET is a C# framework designed for developers and researchers in the fields of Computer Vision and Artificial Intelligence – image processing, neural networks, genetic algorithms, machine learning, robotics, etc.
- AForge.Imaging – library with image processing routines and filters;
- AForge.Vision – computer vision library;
- AForge.Neuro – neural networks computation library;
- AForge.Genetic – evolution programming library;
- AForge.Fuzzy – fuzzy computations library;
- AForge.MachineLearning – machine learning library;
- AForge.Robotics – library providing support of some robotics kits;
- AForge.Video – set of libraries for video processing
are mainly topic in this framework. İf you want more information and help visit: https://code.google.com/p/aforge/
As part of the series of posts announced at this initial blog post (.NET Application Architecture Guidance) that explores each of the architecture areas currently covered by our team, this current blog post focuses on “Microservices and Docker containers: Architecture, Patterns and Development guidance”.
Just as a reminder, the four introductory blog posts of this series will be the following:
- Microservices and Docker containers: Architecture, Patterns and Development guidance
- Web Applications with ASP.NET Core Architecture and Patterns guidance
- Production Ready Cloud applications with Azure Architecture guidance
- Mobile Apps with Xamarin.Forms Architecture and Patterns guidance
The microservices architecture is emerging as an important approach for distributed mission-critical applications. In a microservice-based architecture, the application is built on a collection of services that can be developed, tested, deployed, and versioned independently. In addition, enterprises are increasingly realizing cost savings, solving deployment problems, and improving DevOps and production operations by using containers (Docker engine based as de facto standard).
Microsoft has been releasing container innovations for Windows and Linux by creating products like Azure Container Service and Azure Service Fabric, and by partnering with industry leaders like Docker, Mesosphere, and Kubernetes. These products deliver container solutions that help companies build and deploy applications at cloud speed and scale, whatever their choice of platform or tools…
We can use the Range method to build two integer sequences as follows: You can join the two sequences using the Concat method: You’ll see that the concatenated sequence holds all numbers from the first and the second sequence: