While optimising a query, I noticed that a many-to-many relationship still used a class in between. There is a more optimised way to configure many-to-many relationships in Entity Framework.
In the last post about what I learned in NDepend, I’ll talk about a pragmatic approach to deciding where to refactor code. The combined views of Queries and Rules Explorer, the Queries and Rules Editor and the Metrics view. On their own, they are not that helpful, but combined they contained a trove of data.
The graph is a good way to understand the structure of smaller projects, but gets messy in larger projects. That’s why I compare the matrix of a big project against the matrix of the smaller project.
Since some time, I’ve been wanting to use the NDepend tool to analyse the code base I’m currently working on. Then the opportunity presented itself for me to test out NDepend and see how it can help me understand my current code base better.
Last week, I wrote about the program that will read the emails from my Outlook account. This week I’ll grant the application read rights so that it can actually read the emails.
At work, we made the switch from a local mail server that was accessed over POP3 and IMAP to Office365 Outlook which we access through their RESTful API. To learn more about how this works, I tried to duplicate this process so I can access my personal Outlook emails via a console application.
For a client, I’m working on a portal for their customers. This portal needs to be branded according to the logged-on client. If Microsoft does business with my client and can log into the portal, then the Microsoft logo should appear and all highlight colours should be red, green, blue and yellow.
At work, a number of angular web pages were sending an increasing number of requests to the back-end. Apparently, if I reuse components that don’t properly dispose of their observable subscriptions, they keep sending and processing multiple requests.