Vjeko.com

You might have noticed that I had some problems with pictures on this blog. Some posts simply didn’t show any of them, and I’ve got quite some reports that they aren’t working. Unfortunately, I’ve been so busy recently that I really didn’t have time to look into it. A few days ago, a regular visitor of this blog that goes by the name of Bjarki took time to figure out what’s going on. He posted a comment about his finding, and that’s truly amazing. Thanks, Bjarki! Apparently, when I moved my blog to a new server, for some reason, some of the pictures got referenced with the staging URL…

True, there was no episode 1, not on this blog. But if Star Wars can start with episode 4, I don’t see why can’t I start with episode 2. Especially when Waldo has already written episode 1 . So yes – apparently, up until a few minutes ago – with the new theme my blog has been sporting for a while, it was impossible to search my blog. Somehow, for some reason, the theme I applied didn’t expose the search button in the header, as most modern themes do, and I didn’t notice. But Twitter did notice. And then Waldo fixed it: Well, in any case, it’s there now. Not really…

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…