Notes On 'Visual Basic For Applications' (VBA) In Excel

Purpose And Scope

I want to record some basics and pitfalls of using VBA in Excel, partially just for me, and mostly for Excel users with no prior programming experience.

 

Official overview doc for Excel VBA in particular and VBA in general.  There are also VB.NET docs, which are good for covering some of the gaps in the VBA docs, but sometimes VB.NET is different that VBA (ex: VB.NET has a Return statement but VBA does not).

Git Notes

This will be a continual work in progress and a testament that I should have made this post over a decade ago.

Dedicated fast-forward merge post of mine.

Reminders: the “index” is what holds staged changes. Useful site for undoing/recovering stuff: https://dangitgit.com .

This post and a lot advice and help for git on the internet assumes the command line.  That is because the git command line is same for everyone and easy to give precise instructions.  But really you should try to do as much as possible inside a nice git gui, possibly your IDE or SourceTree.  A nice git gui makes it easy to go from "I want to ..." to "I did it" by exploring menus and possibly right clicking items instead of looking up weird commands and syntax that you will soon forget.  A nice git gui also makes it much easier to see and understand your current repo state and its history.

Git Fast-Forward

Fast-forward merges have properties that are tightly tied together (basically they are equivalent)...

• A fast-forward merge is exactly the sort of merge that doesn't create a merge commit (assuming that you aren't doing destructive operations on commit history).
• A fast-forward merge is exactly the sort of merge that just updates the branch pointer. (Remember that `git pull` first does a `fetch` to get the remote commits before the merge happens, so a merge "just updating the branch pointer" can involve commits that didn't exist locally until the fetch.)
  
• A merge is fast-forwardable exactly when the source commit history is a superset of the destination branch commit history.
• A merge is fast-forwardable exactly when the destination commit is an ancestor of the source commit.

A note on terminology.  I have looked for the most official term for merges that are not fast-forward merges; these are the classical merges that create a merge commit.  The closest I have found is "true merge" as a git-merge reference section header.  Some people use the term "3-way merge" for all merges that create a merge commit, but 3-way merges are an algorithm for producing merge output where you also look at the most recent common ancestor of the two things you are merging, thus the name having "3" in it.  True merges do not have to use the 3-way merge algorithm (see merge strategies).  Thus, I will be using "true merge" or "non-fast-forward merge" to refer to merges that create a merge commit.

Xamarin Pipeline Demo

Table Of Contents

• Introduction
• Notable Files
• Getting Started On Local Machine
• Getting Started On Azure DevOps
• Explanation Of The Journey: Deadends, Pitfalls, Solutions
  • Must Use MacOS Agent
    • MacOS Agent Pitfalls
    • MacOS Agent Directories
  • Fresh Autogenerated Pipeline
  • General Pipeline YAML Advice
    • Pipeline Variables
    • Pipeline Triggers
    • Pipeline Scripts And Strings
  • Give Each Build An Increasing Android App Version
  • How To Choose The Version
  • Build The APK File
  • Sign The APK File
    • Keystore Background
    • AndroidSigning Task
  • Publish The APK Files As Build Artifacts
  • Build And Run Unit Tests
  • Run App Center UI Tests
  • Set Up And Start Android Emulator
  • Build UI Tests
  • Run UI Tests
  • Publish UI Tests
  • Problems Accessing Stuff
• Thanks To Those Who Helped Me

Introduction

I'm making this demo repo and writeup because it was surprisingly and frustratingly difficult to get Xamarin.UITest tests for Android to run on a Microsoft-hosted agent in an Azure DevOps pipeline. NO App Center. NO self-hosted agents. I just wanted to do everything in Azure DevOps.

So, this demo shows how to accomplish that, and some other common goals for an Azure Devops continuous integration pipeline for the Android portion of a Xamarin app...

• Each build gets its own versionCode and versionName.
• Build the APK.
• Sign the APK.
• Publish the APK as a pipeline artifact.
• Do unit tests (NUnit).
• Do UI tests (Xamarin.UITest), which involves several Android emulator steps.
• Publish test results.

This demo is not about getting started on unit testing or UI testing; the demo is about getting these things to work in an Azure DevOps pipeline.

You can see a successful run, a successful job overview, published artifacts, and unit+UI test results (also alernate view for unit test run and UI test run).

This repo is available as a visualstudio.com repo and a github repo. As of 2020-Dec-24, Azure DevOps offers a free tier with 30 build hours per month and 2 GiB of artifact storage. The free tier was more than enough for all the pipeline needs of this demo.

This writeup is available as a github readme, visualstudio.com readme, and blog post. The repo readmes will be kept up to date, but the blog post may not receive many updates after 2020-12-24. Readme section links are oriented for GitHub.

Royal Road To Async/Await

Scope and Purpose

This post will focus on C#'s async/await/Task stuff, as opposed to async/await for F#/JavaScript/Rust.

First, I will try to explain what the await operator does so that readers learn what is actually going on when you await something, and hopefully a bunch of async/await/Task stuff will start to make sense.  A lot of async/await resources don't tell you what is actually going on, so async/await still seems mysterious and full of obscure pitfalls/guidelines.  I want to help my readers take the "royal road" to async/await, getting that major epiphany as soon as possible.

Second, I will present an async/await/Task reading list that is selected and ordered for the benefit of a beginner, with some notes of my own.  The reading list doubles as my own reference of resources that were helpful for me, and as a place to review best practices and pitfalls.  This reading list is another "royal road" to fleshing out readers' understanding.

Note: I'm having trouble with this blog platform display less-than and greater-than symbols correctly, so please tell me if you suspect a formatting error.

Unsigned Integers Are Dangerous

Unsigned integers are dangerous for at least two reasons:

• Danger1: "unsigned integers are highly infectious and possibly lethal to desired arithmetic."  Unsigned integers can transform your nice signed integer math into unexpected and unwanted unsigned integer math.  Ex: the unsignedness of 1u infects the C/C++ expression -1/1u so that it yields a large unsigned integer which may go on to infect more arithmetic.
• Danger2: "unsigned integers almost always teeter on the cliff-edge of underflow, sometimes falling and killing desired behavior."  Underflow and overflow of integers often lead to unwanted behavior, and unsigned integers often hold small values that could easily underflow after common operations like i-- or i-1.  Signed integers often hold small values that are very far away from both underflow and overflow.

Danger1 depends on how your language treats operations with mixed signedness.  C and C++ (and probably many more languages) do have the dangerous behavior of preferring to generate unsigned integers.  Danger2 is for basically all languages.

Due to the severity and generality of these dangers, I recommend the mindset of "use signed integers unless you must use an unsigned integer for a specific reason".  Some acceptable situations to use unsigned integer variables...

• If you have some variable/constant that will only by touched by bit-wise operations and not arithmetic.
• If you really need to be stingy with your variable sizes and need the extra positive range of unsigned integers.

Greasemonkey Journey Notes

Scope And Purpose Of This Post

Holds my notes as I learn Greasemonkey/Javascript/XPath/CSS/HTML/FirefoxWebDevTools.