This week’s tip comes by way of accident.
Here’s the rundown of how this works:
- First, open your Model Driven App, navigate to the end of the URL in your browser, add “&monitor=true” and hit enter
- Next, you’ll see an image that looks like this that appears in the navigation header:
- Click the Monitor icon which will open up a new tab in your browser
- Click “Play model-driven app” from the ribbon which will open another tab
- From here, click “Join” from the “Join monitor debug session?” modal dialog window
- Now you can navigate through your model driven app as you would normally, usually with the assumption of completing user acceptance testing or something similar
- When finished, return to the Monitor tab in the browser and you’ll see the results from your browsing activities
I’m not going to bother re-keying all of the information inside the blog posts linked above because you should definitely go read them thoroughly. However, I’ll highlight some of the most important components of the output so you’ll be enticed enough to dig in further:
- Client specific meaningful events can include:
- Performance counters and metrics (i.e. resource and navigation timings)
- User click events (i.e. controls, web resources, grids)
- Geolocations and preferences (i.e. track user locations, browsers, devices
- Server specific meaningful events can include:
- Execution context (i.e. event and user information)
- Integrations (i.e. request and response information)
- Cross cutting concerns
- Think and trace statements (i.e. think console.log or iTracingService)
- Exception tracking (i.e. handled errors)
Now, if you’re like me, looking through all of that was not just intimidating but a little bit demoralizing. I’m on fire lately with all of the cool stuff I’m learning…but when I see something like this? It all can seem overwhelming.
However, let’s not get discouraged! Small wins, more often…gotta keep reminding ourselves of that…and one of the small wins for this Monitor solution is that we now have an additional tool in our toolbox to performing real-time checks on the load balancing of our code! At the very least, it’s a cool thing to show our clients that can provide some insight into just how much Dynamics is doing behind the scenes to render their business processes for them!
Which brings me to my thoughts on the futility of perceived exceptionalism. The other day, I saw a dev whom I respect post the following on their LinkedIn page (summarized for clarity): “Good job getting those certs, everyone. Not that I haven’t spent the bulk of my career undoing the sloppy mistakes of all the ‘certified’ professionals or anything but good for you!”
The implication, if it’s not obvious already, is that devs are the true heavy lifters on any project and that these certifications are meaningless for most of the functional members of our industry. And I’ll admit? Having used some of the “brain dumps” early in my career out of a sense of pressure to not lose my job? They’re not wrong.
However, I’ve been on many a project where the dev, as well intentioned as they may be, has completely stepped on a landmine in front of the client because their skill set has never even considered what it’s like to be functional. At least, on a real level of shared empathy. You see? NONE OF US IS EXCEPTIONAL. Not one. Yet, we’re all unique and bring a specially-tailored set of experiences that can, and should, add value to the project. If you remember from my last post about the Duplass brothers and their mantra to “make movies, not meetings,” this is precisely what I was trying to convey: if we help guide our clients and team members to believe in their unique skill sets and that each of them provide value to the process improvement as a whole? We’re over half way to a successful project already!
Small wins, more often everyone! Until the next one…