It seemed like a strange request, when a colleague asked me to look into upgrading our Function Apps to use .NET 10, ‘isolated worker’. Since when was it possible to change their runtime version ourselves? And what on God’s Green Earth was an ‘isolated worker’? It was time to investigate.
There are a couple of important things to remember about Function Apps, as a starting point. Firstly, my colleagues and I had developed Function Apps exclusively as custom Logic App components, to handle more cumbersome data transforms.
Microsoft earned itself the rather descriptive name ‘Microslop’ in recent months, on account of having infested virtually all its products with ‘AI’/Co-Pilot stuff that nobody asked for and few want. It’s especially insidious and invasive enough in Windows 11 that one shouldn’t expect any privacy when using it.
Visual Studio Code was a decent editor that I’d been using since Atom got deprecated. Now it’s primarily an ‘open source AI code editor’, its official Web site declares.
Although Substack was never designed to be just a newsletter service for something else, it can be pretty useful for that. I’ve been increasingly less inclined to use it since it became more of a ‘social’ media platform, with certain authors being promoted by The Algorithm. What really did it for me, though, was an email sent to authors the other week, which stated:
‘Substack is introducing age verification steps for those in the UK.
I’m somewhat in agreement with the first half of Jamie Lord’s post on Nearly Right (Engineering leaders demand systems design skills as AI coding assistants produce mounting technical debt), and Jason Gorman made a good point about unreadable code being a form of technical debt (he coined the term ‘codemanship’, which I’m going to borrow). In my opinion, ‘AI’ generated code absolutely should not find its way into the codebase of critical software, unchecked, regardless of what some bastardised implementation of Agile might demand.
Someone wanted files retrieved from a legacy database export. In this case, they were Word documents and PDFs stored as hex strings in an IMAGE column. The hex strings, of course, are representations of the bytes that make up the files. Now, there is a way of recovering files from this, using a native stored procedure, but I didn’t have admin-level access to this particular database. I also couldn’t use the online conversion sites, as the data was too sensitive.
I’ve worked with several ’low code’ platforms in recent years. Some are better than others, but I’m always asking one question: What problems are they supposed to solve?
The biggest of them is ’technical debt’. Dependencies become outdated and unmaintained, updates sometimes have breaking changes that require code to be reworked, additional code gets tacked on over the years by various people, amateur code makes that harder, etc. Technical debt might be an inevitability for an organisation that’s been developing software in-house for long enough.
Typically I find that some troubleshooting and configuration is required to get an imported project to a state where it builds and the unit tests run, and the reasons usually aren’t obvious.
Importing a project Most Mulesoft developers would have made the mistake, at least once, of trying to import a project using one of the options under the ‘General’ section, as that’s the first displayed in the import options window.
Recently I’d been developing a Mulesoft application that uses another as a source API. The response from the source API looks something like this:
{
"nextLink": "https://server:port/external-api/endpoint?page=1",
"nextOffset": 1000,
"morePages": true,
"totalRows": 12345,
"totalPages": 13,
"results":
[
{...}
]
} There are a few things that could potentially be used for paging the response data. As a .NET engineer, I would have approached it by using a While or Until loop on ‘morePages: true’, used the nextLink URI and appended the response payload to a typed list.
After a very busy and difficult couple of months, the system I’d been working on is about to go live to ~27,000 users, and I’m feeling slightly pleased with myself. What should have been a simple integration morphed into a complex Mulesoft project. What a learning curve that was!
The following is my experience with Mulesoft so far.
I think the one advantage Mulesoft has over other platforms - and maybe its selling point - is that the Anypoint portal provides us with a single place from which numerous integrations, API specifications and deployment environments can be managed.
Getting software to work with OAuth is usually one of the easiest things a developer could be tasked with, if s/hehas done it a few times: Create an HTTP client method that sends four values to an OAuth provider, then pass the response to the next HTTP client method as a variable to be used in the Authorization header.
Doing that in Anypoint Studio, for a Mulesoft application, was an uphill struggle of resolving one error message after another.
