I have a bunch of stuff on my mind, and a few topics for blog posts I want to write. But I’m going to start with a little decompression about my work week. (I should first say that I need to be careful about this, since our policy on blogging about work has been tightened up recently. But none of this will come anywhere near to violating it, I think.)
We’re working on an upgrade to our AX environment right now, and we started some testing in a new test environment this sprint. This includes (for me) getting some web services working on the new test server, and getting them to point at the new AX test env. So a lot of my time this week has been spent whacking away at web services with a hammer, trying to get them to work. That’s always frustrating. It always seems like I need to try six different things until I finally hit on the one that actually fixes the issue. And I always feel like an idiot for not being able to get there faster.
I’ve been thinking about why this kind of work is frustrating, and I think a big part of it is having no clue how long it’s going to take, or how close you are to solving it. With certain kinds of work, you can break a problem down into parts, and work through them, so you know when you’re 10% done, or 30% done, or 80% done. But with this kind of troubleshooting, you don’t know if you’re going to need to try 5 things or 10 things or 20 things before you find the right thing. And you don’t always know if there’s one thing wrong, or two things, or ten things.
I won’t get into details on the actual issues I hit, but I will say that one of them was basically a new permutation of this issue I hit back in 2011, so it was fun to see that again! And another one was related to the topic of this post from 2020.
I’ve been using AI tools to help me with this work, and I’m not sure if they’re any more useful than just plain old internet searching. Sometimes it seems like they are; I can get a lot of seemingly-useful ideas from a chat with Copilot. But then the real answer comes from a simple search that leads to a Stack Overflow question/answer, or a GitHub issue. (For instance, one big problem I had this week was solved by reading through this GitHub issue from Microsoft’s WCF repo.)
My big project for this afternoon was working on a side-project for a little competition we’re having at work. (It’s one of those things where small project teams propose something, do a little work on it, then present it to the CIO. And then I guess the winning project actually gets green-lit.) That project is turning out to be a bit frustrating too. (It was supposed to be a nice break from the frustrating stuff!) First, I needed to get myself set up under our corporate developer account with one of the big package carriers, which we only managed to get done yesterday. And I’m still not completely set up, to where I can do what I actually need to do. But I can start testing, so I started work on that.
The project involves using the carrier’s webhook API for package tracking. My idea was to start out with a simple Azure function that I could point the webhook at. Then, to start, I’d just log the info I got from the carrier. The next step would be to hook that Azure function up to some kind of queue in Azure. Then, after that, writing another Azure function that would pick stuff out of the queue and send out notification emails. Basically, I was going to put my AZ-204 skills to work on a real project! (Well, not entirely real, but a POC at least.)
It took me the whole afternoon to get a simple Azure Function set up. I started out trying to use Copilot chat with GPT-5, which they rolled out yesterday, to help me out. That looked really impressive, showing me status info about what it was doing, and generating a lot of text with pretty specific instructions. But it seemed to be giving me quantity over quality. I turned GPT-5 off, and then managed to get a lot farther.
My initial idea was to just enter the C# code for the function directly in the Azure portal, but I set it up in isolated mode, which apparently doesn’t let you edit code directly in the portal. So then I tried using Visual Studio Code, which is supposed to be an easy way to quickly develop and deploy Azure Functions. That led me down a path of installing a bunch of stuff locally. I was initially doing this on my laptop, so I had to install .NET SDK 8, plus a bunch of VS Code extensions. At some point, I got nervous about how much stuff I was installing on my laptop, and switched over to my regular dev VM, which is where I’m supposed to do development. So then I had to install all that stuff there too, since I’d never installed the .NET 8 SDK there, or set up VS Code for Azure dev. So I probably killed an hour just getting my environment set up.
And then, once I had everything set up, I started hitting a bunch of weird little snags with editing, compiling, and running the function. I eventually gave up, and with some help from Copilot, set up the simplest Azure Function project I could, entirely from the command line, then got it running and uploaded to Azure. So that probably took another hour, and the end result was just something that would print “Welcome to Azure Functions!” when you hit the URL for the function.
After that, I got the thing working in VS Code, and managed to change the function from a GET to a POST function. And I thought I had gotten far enough with it that I could hit it from the carrier’s test page, but all I can get back from that is an error, with no details giving me any clue what’s wrong. And that’s pretty much where I ended my week.
I don’t really drink anymore, but I think I kinda want a beer right now. Or maybe just a bowl of ice cream.