Sis Admin's Diary #1 - The start of another week
I thought I'd share my journal for this week, to give some insight into the life of a software engineer. Maybe it would include some career advice.
Since my job is quite varied, there isn't really a typical work day. I'm supposed to be a software engineer, and the thing that got me hired in the first place was my background in corporate .NET MVC application development.
What I actually do these days is a mix of systems administration, patching, documentation and maintainance of several large on-premise legacy services, hence the title of this week's posts. The systems store and process the organisation's most critical data, and nobody else wants to touch them, because any potential change carries a huge risk. And that's not a bad thing for me, in my opinion, because it's important to get some exposure to as many things as one can.
However, I got roped into working on a project that one of the project managers is desperate to get completed this month, and I'm finishing up the development of a couple of services hosted on Microsoft's Azure.
Work-life balance had become very different since working from home became the norm. For many people, it means less time spent commuting and more time spent with loved ones and family. In my case, I'm working at least 10 hours most days, usually between 07:30 and 18:00 - a habit I got into when there were things I needed to check on a server before the admin staff began their days. And I get quite absorbed in the other stuff when my partner works the late shifts in his job.
The air is cold this morning, but the sky is blue. Here in Wales, we normally wake to see everything covered in frost between early November and late February - when it's not raining, that is. Spring is about 16 weeks away. I'm already counting down the weeks to that.
At 07:30, I sign into the laptop and check a few things. VS Code is one of the applications I always have open, as I use the FOAM extension to maintain the vast amount of documentation I'd accumulated for the systems I've developed and maintained. Everyone uses Markdown here, because it's versatile, portable and we can paste documentation straight into the repo wikis. I do wonder why it's still not supported by Microsoft Word, though. I would use Obsidian, but VS Code is standard for development laptops, and the encryption extension is a little better.
Back to the Azure Logic App: The basic components of the service I'm building were easy to set up. I've had to come up with a creative way of combining the responses of several API calls into a single JSON file for the initial data load, because there's too much data for a Logic App to process on the standard tier subscription. I'm also waiting on a systems account to be created to allow the other Logic App to send emails.
For now I'll need to replicate everything from the staging envirionment to the production one. To do this:
- Switch to code view in the Logic App, copy all the code and replace everything in the production version with that.
- In the production version of the Logic App, change all references to the static resources. Will need to switch between designer and code view for this, and check the parameters.
- Copy over all the code for the staging Function App to the production one.
- Upload all DLLs required to the production environment.
- Copy over template files and resources.
- Copy API keys and client secrets from the staging environment's Key Vault.
I needed to add a third-party DLL to the Function App's storage, which has a Web server filesystem. This leads me to believe a Function App can run as a Web applicatiom, with the functions acting as controllers and the contents of the /site directory containing the view layer.
I needed to modify the function's code to instantiate the class in the DLL and pass it to the PDF generator method. Doing this can be tricky for those not experienced with Function App development in Azure Portal, as the 'Intellisense' feature is limited and we can't use breakpoints. Debugging is largely guesswork here, but if we select the 'Filesystem Logs' feature above the console window and click 'Save', it will tell us roughly where the errors are.