Luxoft Training

Anyone who works in IT&C or knows the IT&C market acknowledges that it is very dynamic area, full of challenges and twists. This also means that any company that wants to succeed must make sure that every employee must be capable of adapting to changing situations very fast. The flip side is that with so many changes to deal with it is very easy to drift away from your plans and get yourself, the project or the entire organization into a difficult situation.

In order to understand the types of financial instruments and how they work it’s important to first of all understand the different types of financial markets out there. Some financial instruments can be traded on certain markets while others can be traded on more markets provided they are adapted to the specific requests of each one.

In C# there are quite a lot of features displayed as a rather difficult IL code that lead to behavior not always obvious for the users / code readers. A good example of this is new() exception in generalizations, the use of which leads to using reflection and creating new objects with Activator.CreateInstance, changing the exception's "profile" and negatively affecting performance.

Last time we discussed formatting problems, and now we will deal with exceptions. ErrorProne.NET inherited a lot of features from another project of mine — ExceptionAnalyzer, but in a slightly different form. It includes rules like this:

Everyone makes errors. Even super-qualified experienced developers make errors. Sometimes it happens due to lack of attention or an unclear API. However, those mistakes are rare. Most common programming errors are evidence of insufficient knowledge or skills.

I have been itching for a long time to make an analyzer which would help me catch different errors, specific in varying degrees to the .NET platform. Many of these errors are caught perfectly well by R#, but we always want to create our own stuff, right? Besides, Roslyn analyzers are seamlessly integrated into the build process, they can be used at night (*) and may contain rules specific to your product.

I rolled out the release candidate of the new version of the Code Contracts library last week (v.1.10-rc1). This release has quite a lot of fixes, but the main "new" opportunity is a proper implementation of asynchronous post-conditions.

Design principles play an important part in software development. When combined they make it easy for programmers to develop software that is easy to maintain and extend as well as allowing developers to avoid code smells and refactor the code more easily. Plus they are part of the agile or adaptive software development.

DISCLAIMER: if you took the course Learning How to Learn on Coursera, the book will not be really new for you. On the other hand, if you took a course, then you know that space repetition is a very useful technique, which means the book can be useful even in this case.

As you probably know, the Code Contracts library uses the IL code rewriting to implement contract programming. This "architectural" solution, on the one hand, is quite logical because it allows you to use this library with any programming language of the .NET platform. But, on the other hand, it causes a lot of problems because ccrewrite has to “reverse engineer” the IL code into high-level constructs and rewrite it in a special way.