Self-teaching to be a software engineer, currently know enough to make ok websites and currently trying to learn Flutter.

• Created the repository dexcom, an ongoing project to document and create packages for the Dexcom Share API. I have provided full documentation in that repository, including what it is, how it works, and other things. I have also published a package on pub.dev named dexcom that allows easy usage of the Dexcom Share API.

Here is my versioning standard:

Layout: major.minor.bug (major.minor.bug.specific)

Example: 1.2.4 (1.2.4B)

• major (1): Signifies big new release (0 means beta, 1 means release, 2+ means other big releases)

• minor (2): Signifies some new features, but not too big

• bug (4): Signifies some bug fixes or some small quality improvements

• specific (B): This is platform-specific, so it only shows up per platform. For example, if the bash version is on 1.2.4, and the (future) batch version is on 1.2.4 as well (since they will always be synced down to bug level), if there is a platform-specific bug in the bash version, I can move it up to 1.2.4B and keep the batch version at 1.2.4.

• If you notice that, in a project, the source code and the release don't match, I probably forgot to update one of them. (Fun fact, the entire reason I put version numbers on the source code is for me to keep track)