With .NET Interoperability around, it’s very likely you’ll be synchronously calling external web services from C/AL, to exchange data. I won’t go into discussing whether or not this kind of architecture is good (my own position is that it isn’t), you may end up having situations where your C/AL code simply makes a synchronous call to external systems, such as web services.
Any external call is an expected point of failure. An important question you must always have in mind when calling external functions is transaction integrity. When writing code that targets only NAV, the structure of code is largely irrelevant, as long as you are not using COMMITs (which is another thing you should avoid at all costs). However, as soon as you introduce external calls, the structure becomes critically relevant. Critically relevant.
I’ve talked about this during my 2012 NAV TechDays session, and I promised I’d blog about it – so, here it goes.
Design is one of a kind. Other phases in Sure Step are understood and accepted as good and necessary. But design, do we really do that? Is it really necessary? Who’s going to pay for it? Does the customer really need all those documents? Instead of writing documents, you could have it developed in the same, or less time. And so on and so forth.
As a matter of fact, if you asked me to pick one single most important phase in a Sure Step project, then it’s the design. No second thoughts here, whatsoever.
Here I list the ten most important reasons that I believe make design absolutely indispensable.
“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.
Hint: this is a post for developers, and mostly junior developers, those who are still learning how to code properly. I know, I promised not to blog about stuff like this, but I simply couldn’t help this time.
A friend of mine has asked me for help.
“There is this C/AL function I had to rewrite, now I end up with 106 BEGINs, and only 105 ENDs. Do you have any idea how to find where this missing END belongs?”
WinDays 2008 are over. Somehow, this conference has become a milestone, in Croatian ICT community, in Microsoft community, even in my life. I met a friend there, one of those I only meet there, and realized just how quickly the year turned. Obviously, I contemplated too much, and partied too little, something to really get worried about.
Anyway, the presentations I delivered made me think about the future of this blog. It started pretty randomly, as a place where I simply dumped anything that crossed my mind, so you had all sorts of content, from programming, to development, to functionality, to theory. When I look at my blog to-do list, there is even more chaos to it, with topics ranging from SQL optimization all the way to business process reengineering. I realized I need more focus. Continue reading WinDays 2008: Aftermath→