Vjeko.com

I’ve been absent for a while – sometimes it’s difficult to find time for blogging even when I want it. Anyway… here’s the last post in the introductory series of posts that explain my NAV TechDays 2019 demos. In this code example, I explain the difference between typical development and production build configurations, and I show how to configure gulp accordingly. To check the code example, and to read the detailed explanations of it, jump over to https://github.com/vjekob/supercharged_01/tree/08-gulp-build-prod Development and production configurations are not an intuitive thing…

I’ve been absent for a while – sometimes it’s difficult to find time for blogging even when I want it. Anyway… here’s the last post in the introductory series of posts that explain my NAV TechDays 2019 demos. In this code example, I explain the difference between typical development and production build configurations, and I show how to configure gulp accordingly. To check the code example, and to read the detailed explanations of it, jump over to https://github.com/vjekob/supercharged_01/tree/08-gulp-build-prod Development and production configurations are not an intuitive thing…

After a short absence, I am back. The next lesson in the Control Add-ins Supercharged series I am introducing Babel . “Babel is a JavaScript compiler” , says babeljs.io. So, what’s the big deal, you may ask? The big deal is that Babel will take your super-fancy high-end future-generation JavaScript code that barely any browser supports, and turn it into something that even Internet Explorer can run. In theory, at least. In practice, it’s a bit more complicated. To learn about theory and practice of Babel in control add-in development workflows, check this branch: https://github.com/vjekob…

After a short absence, I am back. The next lesson in the Control Add-ins Supercharged series I am introducing Babel . “Babel is a JavaScript compiler” , says babeljs.io. So, what’s the big deal, you may ask? The big deal is that Babel will take your super-fancy high-end future-generation JavaScript code that barely any browser supports, and turn it into something that even Internet Explorer can run. In theory, at least. In practice, it’s a bit more complicated. To learn about theory and practice of Babel in control add-in development workflows, check this branch: https://github.com/vjekob…

One of good practices of writing C/AL Code for Microsoft Dynamics NAV since the dawn of civilization was annotating (commenting) code changes. If you are not sure what I mean by that, this is what I am talking about: While standards varied about > vs +, or < vs -, or what the annotations should include, there was absolute consensus that annotating changes is an absolute must. And it was a must. It was such an important rule that everyone followed it without questions asked. In my career, I’ve seen one or two situations of somebody changing or deleting a line of code without leaving…

One of good practices of writing C/AL Code for Microsoft Dynamics NAV since the dawn of civilization was annotating (commenting) code changes. If you are not sure what I mean by that, this is what I am talking about: While standards varied about > vs +, or < vs -, or what the annotations should include, there was absolute consensus that annotating changes is an absolute must. And it was a must. It was such an important rule that everyone followed it without questions asked. In my career, I’ve seen one or two situations of somebody changing or deleting a line of code without leaving…

So far I’ve shown how to configure gulp to help you with some basic JavaScript development tasks, such as bundling and minifying, and how to automate builds on every source file change. Let’s now take it to an entirely new level: debugging. If you ever tried to debug your control add-in source code using Visual Studio Code, you might have realized two things: first, that it’s actually pretty simple to do; and second, that it’s not the kind of debugging that you want. Let’s see why that is. First, using VS Code with a browser such as Chrome, Edge (especially “Canary”, mmmm) or Firefox is…

So far I’ve shown how to configure gulp to help you with some basic JavaScript development tasks, such as bundling and minifying, and how to automate builds on every source file change. Let’s now take it to an entirely new level: debugging. If you ever tried to debug your control add-in source code using Visual Studio Code, you might have realized two things: first, that it’s actually pretty simple to do; and second, that it’s not the kind of debugging that you want. Let’s see why that is. First, using VS Code with a browser such as Chrome, Edge (especially “Canary”, mmmm) or Firefox is…

Yesterday you’ve seen how to use gulp to make it do something truly useful: bundling your JavaScript and CSS files. Introducing gulp for the purpose of bundling your files allows you to split your functionality into as many files as you want, but use only a single script and a single stylesheet file from your control add-in. That way you not only optimized how your browser loads the files, but you also eliminated the need to maintain your controladdin object file every single time a new JavaScript or CSS file is added (or an existing one is removed). However, you still need to run gulp build…

Yesterday you’ve seen how to use gulp to make it do something truly useful: bundling your JavaScript and CSS files. Introducing gulp for the purpose of bundling your files allows you to split your functionality into as many files as you want, but use only a single script and a single stylesheet file from your control add-in. That way you not only optimized how your browser loads the files, but you also eliminated the need to maintain your controladdin object file every single time a new JavaScript or CSS file is added (or an existing one is removed). However, you still need to run gulp build…