• Passed AZ-204

    I just passed the Microsoft Exam AZ-204: Developing Solutions for Microsoft Azure, which qualifies me for the Microsoft Certified: Azure Developer Associate certification.

    Microsoft Certified: Azure Developer Associate badge

    View my verified achievement from Microsoft

    If you take a look at the skills measured for this exam, it really does cut across a lot of Azure technologies. I hadn’t had deep exposure to all of those even though I’ve been using Azure a lot lately. So to maximise my chances in the exam I also spent time complementing my hands-on experience with some learning and training content:

    1. Completing all the learning paths listed under Microsoft Learn’s AZ-204 Two ways to prepare heading.
    2. I also reviewed all the content in Pluralsight’s Developing Solutions for Microsoft Azure (AZ-204) certification path. Use this link https://referral.pluralsight.com/mQlUV3B to get 50% off your first month or 15% off an annual subscription!

    Like my previous exam in January I took this one at home. One slight hiccup was that despite Pearson VUE’s website clearly saying an external monitor, keyboard and webcam are acceptable as long as your laptop lid is closed (mentioned under ‘Make sure you have the right equipment, Required if using an external monitor with a laptop’), the proctor insisted that was not allowed. I wasn’t going to argue but it was a bit confusing.

    I’m thinking the next exam on my list might be AZ-400: Designing and Implementing Microsoft DevOps Solutions, as when that is combined with today’s effort I’ll be eligible for the Microsoft Certified: DevOps Engineer Expert certification.

  • Which Western Digital Red 4TB NAS hard disk should I buy?

    Back in April I mentioned purchasing two Western Digital Red NAS 4TB hard disk (Model WD40EFRX).

    I’m thinking about buying another one or two similar drives, but on closer inspection I noticed that there’s a few different WD Red 4TB drives to choose from.

    Western Digital Red 4TB SATA Drives

    Model number Transfer rate Internal rate Cache RPM Recording Technology Approx. Date Spec sheet Amazon AU Amazon US
    WD Red WD40EFAX 6 Gb/s 180 MB/s 256 MB 5400 SMR Aug 2020 Link AUD134 AUD127
    WD Red Plus WD40EFRX 6 Gb/s 150 MB/s 64 MB 5400 CMR May 2014 Link AUD165 AUD273
    WD Red Plus WD40EFZX 6 Gb/s 175 MB/s 128 MB 5400 CMR Jan 2021 Link AUD163 AUD162
    WD Red Pro WD4003FFBX 6 Gb/s 217 MB/s 256 MB 7200 CMR Sep 2020 Link AUD217 AUD192

    Notes:

    • Prices were at 15th July 2021, and were captured in Australian Dollars (your currency may differ). Click through to the links to get the latest price. Most Amazon links above are affiliate links.
    • Dates are from the oldest specification sheets I’ve found for that model.
    • Recording technology: SMR - Shingled Magnetic Recording, CMR - Conventional Magnetic Recording. More info

    I also found a useful overview of the Red, Red Plus and Red Pro lines.

    Looking at that data it does look like for the ‘Pro’ line the WD40EFZX represents better value, but for the home enthusiast the WD40EFAX seems reasonable.

  • GitHub Actions default environment variable gotcha

    I was trying to use a GitHub Action default environment variable in a workflow today, and was surprised to find that it didn’t work as expected. The workflow contained a step similar to this:

    jobs:
      build:
        steps:
            - name: Output job info
              run: echo "Job '${{ env.GITHUB_JOB }}'"
    
    

    According to the documentation, GITHUB_JOB should contain the job_id of the current job. In this workflow, the job_id should be “build” (as that’s the name of the current job).

    But when I ran the workflow all I got was Job ''. I found a couple of posts that seem to hint at the answer.

    GitHub sets default environment variables that are available to every step in a workflow run.

    In short, the documentation seems to be a little misleading here. The ${{ env.xxxx }} notation works find for env: context variables that you’ve defined yourself, but not for the default environment variables. Either refer to the variable in the way appropriate for the script language (if you’re using run), or if you’re setting a property for an action you can use a different approach. eg.

    jobs:
      build:
        steps:
            - name: Output job info
              run: echo "Job '$'"