Decoupling

Read more about the article Testing in isolation

Testing in isolation

  • Post comments:14 Comments
  • Reading time:40 mins read

An AL developer gets fired from his job for writing inefficient tests. With his LinkedIn profile proudly showing off his extensive testing experience, a car manufacturer hires him to test cars. His first assignment: test the oil lamp. So he imagines a test, applying his vast experience:

// [GIVEN] A car
// [GIVEN] Enough fuel
// [GIVEN] Engine oil within operational limits
// [GIVEN] Engine runs long enough

// [WHEN] Oil level drops below operational minimum

// [THEN] The oil lamp turns on

Spoiler alert: the guy’s gonna get fired again.

(more…)

Continue ReadingTesting in isolation
Read more about the article Resident control add-ins – no SingleInstance

Resident control add-ins – no SingleInstance

  • Post comments:0 Comments
  • Reading time:17 mins read

My last topic was resident control add-ins. In my video and written blog I’ve explained what they are and how you can quickly have them up and running. However, there was one particular thing I said I generally don’t like – single-instance codeunits. So my second blog on this topic focuses precisely on that: how to make your control add-in available to your AL code from everywhere, without having to rely on a single-instance codeunit.

(more…)

Continue ReadingResident control add-ins – no SingleInstance

Decoupling dependencies in C/AL

  • Post comments:8 Comments
  • Reading time:12 mins read

Directions US 2016 (yes, 2016, sorry y’all who got the 2017 link in your mailbox) was quite an event. As Directions always is, a lot of people, enthusiastic about this market we strive to thrive in, and about the product we love no matter the limitations we often face when we aim for better, more scalable architectures.

If anything, it reminded me of a long to-do list I have had around for this blog for a while, and I decided to start cleaning it up. The topic of my main session this year was loose coupling of dependencies (I called it polymorphism, because that’s what I’d ultimately like to see possible in C/AL) and I presented two patterns I came up with during my past few years.

Before I present them here on my blog, I wanted to put them in a broader context: loose coupling. So, this is what this post is all about: explaining what loose coupling is, how to achieve it in C/AL, and why you will not want to live without it ever again.

(more…)

Continue ReadingDecoupling dependencies in C/AL

I had a dream: decoupled NAV

  • Post comments:4 Comments
  • Reading time:18 mins read

You know about PRS (Partner Ready Software), don’t you? It’s the initiative started by Mark Brummel, Eric Wauters (Waldo), and Gary Winter (not necessarily in this order), and then they decided to expand their team by one more member. I am not quite sure if this was a good move, but the time will tell. It always does.

The main goal of the initiative is to enable you to customize NAV in a repeatable way. Repeatability is kind of a buzzword, but PRS doesn’t just buzz the word. PRS believes repeatability is the key. Today maybe you don’t care about repeatability. In two years, or latest five, you’ll want to go back and rethink your angle. PRS wants you to rethink now.

One way of getting repeatable customizations is through patterns. There are patterns, all over NAV, that repeat, time after time, over and again. Agosto dopo agosto dopo agosto dopo agosto as Jovanotti would put it. Pun intended. When a pattern repeats itself, it’s repetition, not repeatability. There is a big difference between them, big as a house. To get repeatable, is to get rid of repetition. Instead of having essentially the same piece of code all over the place with a hint of Goldberg Variations, how about having it only once, in a single place?

Like, having one place where you assign a number from a number series to any master record, document, journal, you name it. Instead of at least—let me guess—120 different places in about as many objects. Then, if you want to customize one small aspect of it, you just touch that one single place. You can then repeat the same customization for hundreds of customers, not only surviving the version upgrade, but making it (the upgrade) an essential, non-disruptive, piece-of-cakeish part of your service offering. That’s the repeatability that PRS is all about.

But—there is always a but—the way NAV is today, we are a long way from this kind of repeatability. A long and painful way away.

That’s why I had a dream. I know it’s only a dream because to make NAV do what I am about to share here would be to downright rearchitect it from the core. But I’ll share it nonetheless. Keep reading.

(more…)

Continue ReadingI had a dream: decoupled NAV