Whoa! This has been quite an event, the Directions EMEA 2016 in Prague. There has never been this many people (1.700+) and it was quite a pleasure connecting again with old friends, and meeting new friends. Also, it has been quite a pleasure listening to many good sessions, and an even bigger pleasure delivering four of them.
And this is why I am blogging now – to follow up on my promise during my Polymorphic Event Patterns for C/AL. I promised you that I’d post my pattern proposal online, and here I am doing it.
The purpose of events is to simplify business logic customization while not impeding upgradeability and general extensibility. However, there is one particular class of events that may cause troubles: OnAfter* table events. There are four of them: OnAfterInsert, OnAfterModify, OnAfterDelete, and OnAfterRename.
Microsoft Dynamics NAV Team Blog has just published a mega-useful post about recommendations for configuring Microsoft SQL Server for optimum Microsoft Dynamics NAV Performance. If you haven’t yet, you should check it here.
The blog post delivers a PDF document summarizing certain important parameters, configuration settings and suggestions for improving and maintaining a speedy SQL Server for your NAV installation. The recommendations have been written for x64 version of SQL Server 2005 SP3, SQL Server 2008 SP1 and SQL Server 2008 R2. The document was compiled by Michael De Voe, a Senior Premier Field Engineer at Microsoft specializing in performance, scalability, infrastructure and high-availability for in NAV and AX.
So I would guess that was it. I’m just returning to Kristiansand, my Norwegian base, after delivering the “Microsoft Dynamics NAV 2009 Development Best Practices” course to a partner, my first custom-developed training ever. My impression is—mission accomplished.
I was not sure at first how this would turn out. Teaching NAV best practices to people some of whom have more experience than I’ll have any time soon, isn’t an easy thing. The challenge for me was—how to deliver something new, really valuable to those people, something they could go home with saying “wow, if only I knew this earlier”.
“Best practices” is one of those beloved and hated concepts. There are people who just embrace “best” practices for the sake of their bestness. And there are people who just shun them for the very same reason—those know-it-alls who have opinion on everything and know it better before even learning about it. What’s-best-for-you-is-not-best-for-me kind of people. Neither of approaches is actually, well, best.
For a best practice to be the best for you, you need to understand it, and if you find any pitfalls, improve it.
In two days I’m delivering the NAV Development Best Practices training for a service provider in Norway. They approached me two two months ago and asked if could do something like that. This brought to memory some good posts I made years ago, and here I bring the links. If you want me to share my best practices, this would be my starting point:
Code of Coding: emphasizes the need for understanding the effects of a change in code, and making others understand your intention
Code of coding 4: Die, hard(coding) 2: about avoiding embedding settings into code, with detailed explanation what exactly is wrong with it, and some good guidelines on how to detect less obvious cases of settings hardcoding
NeverENDing story: about a very bad example I once encountered, and how to avoid situations such as that
Featuritis Cure: now this one is definitely not a “best practice”, it’s about a situation when a developer pulled a prank on a customer so subtly that I just had to share it with the world. A far better cure for Featuritis (a dangerous and ugly disease indeed) is given by Mark Brummel, in his fantastic post Tip #20 – Save Report Usage. If you aren’t yet following Mark’s blog, now would be a good time to start.
If you are interested in development best practices, check these posts, and if you find them useful, then I’m happy. If you don’t, share your thoughts. Best practices develop over time, improving slowly, and gradually until one day they just become the norm.