Author Archives: Soren Klemmensen

About Soren Klemmensen

Another Microsoft Dynamics 365 Business Central geek

Social Listening

While on MSDN I came across some new Help Content for Dynamics NAV 2015 talking about Social Listening.

Now while Social Listening might not be on everybody’s “must have list” it is still a great way to show the power of Dynamics NAV and the application stack from Microsoft.

I look very much forward to see what these new topics mean for the product.

Have a look here:

https://msdn.microsoft.com/en-us/library/dn889763(v=nav.80).aspx

Update:

I was made aware by Vjeko that there is an “How Do I” YouTube video on the topic too…

https://www.youtube.com/watch?v=8QO9U1h921c

Mixing concepts – code vs. translations

In my little miniseries here of things we can do better I would like to put focus on another conceptual issue that we really need to deal with too.

Code and Translations are 2 very different things and they should never be mixed. Okay I said it and maybe I will get a little verbal beating for doing so, however it doesn’t make it less true.

The way we deal with translations today by putting them into the compiled objects has its roots a very long time back in the application. Long before Dynamics NAV had a service tier. Long before we had even considered SQL as a database platform and maybe it is time to rethink that again. I am not saying that they did it wrong when they created translations the way the work today, but I am simply saying that the times has changed and so should the product.

Purely form a conceptual point of view Code and Translations should never be mixed. It is simply a bad practice.

Now we can technically already do this as we can host the translations on the service tier and not include them in the code, however this is not the standard way and unless you work with a country that needs this, we hardly ever see this in any install.

You can read all about how this is done on MSDN here:http://msdn.microsoft.com/en-us/library/dn479852%28v=nav.80%29.aspx

Now at this point Microsoft doesn’t recommend this unless needed because it is slightly slower than using the translations when compiled into the objects. So you have been warned… J

In a side note when it comes to this discussion: “Why do we handle translations the way we do?”

Take a word like “Customer”. The word is translated many times because it exist in many locations across the code, but why do it that way? This is not a very efficient way of handling the translations and it would be far more efficient if we stored this translation once and pointed to it many times based on need. This would also greatly help when a given translation needs to be changed by a partner for a given vertical as I am sure many of you have tried.

I want to see our great product become even better than today. We need to constantly improve to stay in the lead. Removing these simple inefficiencies, so partners and developers can concentrate on building great products, will surely benefit us all.

Fixed text format

If you are working with NAV and Source Code Management you will know how easy it is to get a text file exported in the wrong format. The formatting of dates and numbers is done differently from country to country and even inside some countries causing issues with your source code management if everybody in your team don’t make sure to export with the agreed regional settings.

What makes it even worse is if this code finds its way into your source code as you will most likely not be able to do your build from it. Because the dates and numbers now are formatted wrongly your import of the text files fails or even worse imports them incorrectly.

In any case that is not what you would want to see happen and as an avid Source Code Management advocate it bugs me.

The solution would be that we had a fixed format in the export/import that would be independent of your regional settings. What if text export always, without exception, exported in one format and imported in the same format. Would that cause problems? I don’t think many would have issues with that.

In other words a good suggestion to improve Source code management adoption would be to create exactly this.

Just saying 🙂

Codeunit 1 Merge Conflict Issue

If you have ever merged Codeunit 1 you will have noticed that you always get a merge conflict in the functions ApplicationVersion and ApplicationBuild at least if you have added your own versioning which most vertical solutions would have done.

Standard the 2 functions look like this depending on what Cumulative Update you are on

And typically I would add my own function call (Hook) inside the EXIT to call and add my version or build number.

The result of this is of course that in the next merge I have changed this line and so has Microsoft giving me a conflict, which I will get every single time I try to implement a Cumulative Update. Very annoying to say the least and with no good work around.

So what would the solution be?

Well if Microsoft would add a standard hook here to an empty function returning nothing we as partners would be able to add our hooks in this function and avoid the conflict.

Now that resolves the major part of the problem as long as we as partners also remember to add our code nicely here, so we don’t start getting conflicts when using each other’s add-ons.

Comments are evil

I have often had the discussion with somebody about commenting code.

I have heard all the arguments:

  • We need to comment code, so we can see what code we took out or changed.
  • We need to comment code, so we can see who did this, when and why.
  • We need to explain what this code does, so it is easy to understand for the next guy.

I am sure there are many others, but it doesn’t change my view that COMMENTS ARE EVIL.

First of all Comments can be 1 of 3 things:

  • Correct
  • Misleading
  • Out right wrong

Best case if of course that they are right. That is what we all strive for, but sadly rarely archive. In most cases they are misleading because the written language isn’t code and rarely clearly define what we really mean to say. It is simply too complex in many cases to say something described in the code in the written language without missing something. I guess that is why we write code and not novels. Then there is of course the case when comments are out right wrong because we forgot to update them or because we just wrote them down all wrong.

Generally Comments are just a way to hide bad code. The only true comment is the code and it should be written clearly and well-defined so it is easy for anybody else to read and understand. Always look back at your code. If it is hard to read and understand you should most likely rewrite it.

Then there are the arguments that we need to be able to see what we changed compared to the standard code form Microsoft. Just another excuse used by people that don’t use a proper source code management tool like Team Foundation Server or Visual Studio Online. The latter is free for up to 5 users and most of the job can be automated via PowerShell so there is really no excuse. The new tools we got to merge code from Microsoft in the form of PowerShell cmdlets also doesn’t need comments or the old code to work. More often these comments might actually confuse the tool.

Oh yes and then there of course is the arguments that we need to understand who did something and why. Again that is why you should use a complete tool like Team Foundation Server or Visual Studio Online where you can track and manage your development work. What exactly comes out of our development team? Track it both from your tasks and requirements to the code and back.

When it all comes down to it there is really no getting around it that COMMENTS ARE EVIL and we should try to do better.

Passing Records and RecordRefs via Variants

As developers in an ever more repeatable world we should strive to write code in ways that make it as flexible and generic as we possibly can. A trick I use is too pass things around in ever more generic ways by using Variants.

A good example can be seen below where the function ReturnRecordIDasText function takes either a Record or a RecordRef as input and then returns the RECORDID as text.

The important thing to notice here is of course that the function can take more than one datatype as input giving the function even greater usability.

Before anybody notice I better say that passing variables by reference is a limitation of the example above. Still a good trick though according to me.

Hopefully you find this trick useful too.

PS. I have seen Waldo use the same trick in a slightly different way, so credit should absolutely also go to him in this case.

Comment and Uncomment Selection – New feature in NAV 2015

One of the small features in Microsoft Dynamics NAV 2015 is the ability to comment a selection of code.

Now I am not a huge believer in putting comments in code. Actually I am of the school that think comments are evil, because code should be written so it explains itself. That aside I find the new feature handy when testing and you want to take something out just for a test run.

How does it work?

If you are in the code you can mark a few lines of Code like this

Then click “Comment Seletion…” under the Edit Menu or use the shortcut Shift+Ctrl+K and the marked lines will be commented out by setting 2 forward slashes in front of the code at the left margin.

There is also an “Uncomment Seletion…” with the shortcut Shift+Ctrl+O that will remove the comments again.

Absolutely a help to developers, but please consider how you use comments.

Comments should not be needed in the final version of great code.

How do I Videos

Back in April I posted an index of “How Do I” Videos on this blog. I felt there was a need to have them indexed somewhere, so everyone can find this great work in an easy way. It is such a great resource for so many things and I use them myself frequently.

Yesterday I noticed that all the videos are nicely indexed on MSDN and I thought that was worth a blog post to share.

http://msdn.microsoft.com/en-us/dynamics/nav/ff518990

NAV Directions 2014 in San Diego

Have you signed up yet?

Well if not, you really need to get it done.

Directions is the one big event every year that is exclusively dedicated to Microsoft Dynamics NAV on the North American continent and everybody should make sure to be there.

Maybe you are a smaller partner, bigger or some were in between and you really don’t see why you should invest in this event, but this year it is more important than ever. Like I wrote recently in my “Do or Die with Microsoft Dynamics NAV” blog post, things are changing and they are changing fast. If you don’t change I doubt you will have a chance to make it in the coming years.

The competition is hard out there with major players that will eat your segment for breakfast and that at a price point where you cannot compete unless you change and now.

Looking at the great many sessions this year it is clear that there is a lot of focus on this from Microsoft & the community. Very much energy has gone into putting sessions together that help explain what we need to do to be successful in the future with cloud, multi-tenant and a very different looking ERP market.

Sign up today and start your change…

http://navdirections.com/

DO or DIE with Microsoft Dynamics NAV

Do I have your attention now… or should I have called it “An Inconvenient Truth

Dynamics NAV greatest strength is its amazing ability to easily be modified & customized to individual needs, but it is also the greatest weakness. Said in other words: “With Great power comes great responsibility”

You might be thinking by now: “What is this guy talking about?

Well far too often (and I have fallen victim myself from times to times) we make changes to NAV because we can. It is easy and what the customer is asking for, but we forget to qualify if this is the right thing to do!

Henry Ford once said that, if he’d asked his customers what they wanted, they’d have asked for a faster horse.

In our Dynamics NAV world this is especially true. We as partners needs to be the leaders and figure out what the customers really need instead of what they are asking for, but currently far too few of us do that.

This all comes down to a few things: Product Management… Source Code Management… Product Life Cycle… Agile development…

Product Management is among other the ability to filter through customer demands or requirement. The ability to understand the market you are working in & the ability to ask the right questions to get to the root of the problem or requirement.

What is it the customer REALLY is looking for…? What is his fundamental need?

Sadly Product Management is far too often overlooked and many even don’t have this as a job function in their organization.

You might ask: Why?

Well the classic way in the NAV world has been to locate a customer, sign a deal and develop a solution that fit his needs. The consultant and programmer (often one and the same person) was on the front line and gave the customer what he needed. It was easy. It was quick and it generated revenue. End of story. In short it is much easier to give the customer what he thinks he needs instead of figuring it out.

I guess this story is still true in many cases, but this world is dying and if you don’t want to die with it, you need to change gear. Change the way we think about everything.

If you think you can compete with somebody that delivers one solution, but can deploy it 200 times, 500 times or a 1000 times you are sadly mistaken. They can afford to put much more into the product in the form of functionality, testing, upgrading than you will ever be able to in the “one of” individually customized installation.

Source Code Management is another area far too many try to avoid. Many have told me through the years that this is just overhead and brings no value to the product. Nothing could be further from the truth.

That ability to know WHAT you are doing (The source code changes) and WHY you are doing it is true product management. It is true Product Life Cycle management because you now develop your product in a direction with a clear goal and understanding of why and what it takes to make your vertical a success.

How to get it done?

The next question is how to get it done. Well it is all about selecting the right tools.

Team Foundation Server from Microsoft is my preferred tool, because it is doing all of this in an integrated way. Source Code is stored and linked directly to tasks. Bugs & Product Backlog Items are managed, prioritized and linked to Features.

This is also completely integrated to Visual Studio which already should be your developers preferred tool of choice for anything in the non NAV world of programming.

If you don’t want to install it you can use the cloud version that you find athttp://www.visualstudio.com/ Yes you need to pay for it if you go above a certain number of users or if you want to access all the features, but cloud services are the way of the future, so get over it.

Best in class development practices is another fundamental way we need to change the way we think. The Partner Ready Software guys have been working on this for years. There is a new initiative on the community side about Microsoft Dynamics Design Patterns, but it also comes down to your team of developers. Do we give them time to research the best ways to do development? Do we encourage code review? Do we put time aside to refactor code?

We can continue doing what we have done in the last many years and gaining another 100,000 customers worldwide over the next 25 years for NAV or we can change gears and add another 100,000 customers every year. I know what ship I want to sail on.

 

It is DO or DIE time folks