NOTE: Some of the links below may be affiliate links. Nevertheless, I don’t put affiliate links to things unless I’ve personally used/vetted them. Feel free to contact me if you have any questions.

Books

• Figure Drawing for All It’s Worth - Andrew Loomis - This has been my primary study material for figure drawing. I worked through this book page by page, redrawing many of the poses in here as per Loomis’ method. I feel like my figure drawing improved significantly after going through this book.

• Drawing on the Right Side of the Brain - I have mixed feelings about this book, but I would still recommend it to very early beginners. It has some good lessons, but I personally felt like I needed to quickly move on from the lessons in this book.

Supplies

TBD

Online Resources

• RadioRunner’s Curriculum for the Solo Artist - Original Post - RadioRunner compiled an awesome list of online resources a few years back, and posted it to Reddit. I’ve used this list as a hub to find some of the best resources for the topics I want to study. Strongly recommend going through it.
• RadioRunner’s Curriciulum for the Solo Artist - Online Version - The above hosted in web format, with clickable links.
• Croquis Cafe - Really helpful resource for quality poses.

Getting Started

First, familiarize yourself with the community offerings for GitHub Actions - game-ci/unity-actions. There’s a good overview here in the readme of the supported actions.

The other thing to check would be the official game-ci getting starting docs.

Setting up License

The instructions in the official docs aren’t the most verbose, but it’s actually quite simple.

I’ll just go into a little more detail here to try to make things super clear.

Step 1 - Request Activation File on GitHub

This is an action that is intended to be a one-time use. Its purpose is to create a “license request file” that will be needed for the next step. This is what will allow unity to run builds on the GitHub Actions servers.

The file should end up looking something like this:

.github/workflows/activation.yml:

name: Acquire activation file
on:
  workflow_dispatch: {}
jobs:
  activation:
    name: Request manual activation file 🔑
    runs-on: ubuntu-latest
    steps:
      # Request manual activation file
      - name: Request manual activation file
        id: getManualLicenseFile
        uses: game-ci/unity-request-activation-file@v2
      # Upload artifact (Unity_v20XX.X.XXXX.alf)
      - name: Expose as artifact
        uses: actions/upload-artifact@v2
        with:
          name: ${{ steps.getManualLicenseFile.outputs.filePath }}
          path: ${{ steps.getManualLicenseFile.outputs.filePath }}

After you push it up, you can manually run the worfklow to generate your license.

To find this file, go to GitHub > Your Repository > Actions. Click on the commit that last ran. You should find a file named something like Unity_v2019.3.14f1.alf. (The exact name depends on the version string that you put in unityVersion above.)

You’ll need to save this file locally for use in the next step.

Step 2 - Request License from Unity

Head over to the Unity Manual Activation link.

Here you simply upload your .alf file from the previous step. Fill out the form with your license details.

On the last step you should be able to download a file that ends in .ulf.

This is your license you will put in GitHub secrets for use in your build actions.

Step 3 - Save License in GitHub Secrets

Open GitHub > Your Repository > Settings > Secrets.

Create a secret called UNITY_LICENSE and add the contents of the obtained license file (.ulf). Yes, add the entire XML contents to the GitHub secret.

Now that this step is done, you can delete the .github/workflows/activation.yml file.

Set up workflow

Now’s the fun stuff! Now that you have your license ready to go, you can start setting up actions.

A couple of best practice recommendations:

• Cache your Library folder. This is where all your cached packages and large files end up during builds.
  • Note caches created on branches are scoped to that branch, regardless of key matches. Same goes for tags.
• Use GitHub Releases to store your file, not actions artifacts. You will quickly run into free limits using artifacts
• Due to the size and time of full builds, I like to generate target builds only on tags.

Here’s an example of a couple of workflow files.

Test - Runs on every commit

.github/workflows/test.yml:

name: Test

on:
  pull_request: {}
  push: { branches: [master] }

env:
  UNITY_LICENSE: ${{ secrets.UNITY_LICENSE }}

jobs:
  build:
    name: Test project
    runs-on: ubuntu-latest
    steps:

      # Checkout
      - name: Checkout repository
        uses: actions/checkout@v2
        with:
          lfs: true
    
      # Cache
      - uses: actions/cache@v2
        with:
          path: Library
          key: Library

      # Test
      - name: Run tests
        uses: game-ci/unity-test-runner@v2
        with:
          unityVersion: 2020.3.15f2

Build - Runs on tagged commits

This file uses this on.push.tags trigger to only run when tags are pushed.

It then uploads artifacts, zips up the binaries, creates a GitHub release for the tag, and uploads the release assets to it.

Depending on your usage, you might not want to upload the artifacts. You’ll quickly run into limits if you use it too much.

.github/workflows/main.yml:

name: Build

on:
  push:
    tags:
      - '*'

env:
  UNITY_LICENSE: ${{ secrets.UNITY_LICENSE }}

jobs:
  build:
    name: Build my project
    runs-on: ubuntu-latest
    steps:

      # Checkout
      - name: Checkout repository
        uses: actions/checkout@v2
        with:
          lfs: true
    
      # Cache
      - uses: actions/cache@v2
        with:
          path: Library
          key: Library

      # Test
      - name: Run tests
        uses: game-ci/unity-test-runner@v2
        with:
          unityVersion: 2020.3.15f2

      # Build
      - name: Build project
        uses: game-ci/unity-builder@v2
        with:
          unityVersion: 2020.3.15f2
          targetPlatform: StandaloneWindows64 

      # Output 
      - uses: actions/upload-artifact@v2
        with:
          name: Build
          path: build

      - name: Zip build
        run: |
          pushd build/StandaloneWindows64
          zip -r ../../StandaloneWindows64.zip .
          popd

      - name: Release
        uses: softprops/action-gh-release@v1
        with:
          files: StandaloneWindows64.zip
          name: Release ${{ github.ref }}

Note: If you’re using the above workflow, and experience an error on the build step like this:

Warning: Changes were made to the following files and folders:

Warning: ?? artifacts/

Error: Branch is dirty. Refusing to base semantic version on uncommitted changes

You will need to add the artifacts folder to your .gitignore file, as referenced in this GitHub issue.

Another option would be using the allowDirtyBuild flag if you are still running into dirty branch issues.

Feel free to customize for your use case, as this workflow only outputs windows binaries. However, as mentioned in game-ci/unity-actions, there’s a ton more supported actions/options.

Conclusion

Setting up a CI flow early tends to keep me honest in following best practices. I like to do it even for my hobby projects.

A good side effect, is if I have to let projects idle for a while, I can always come back and expect my builds to work.

Related Links

• Unity Plus - Unity Pro
• Github - Unity Actions - Unity Actions for GitHub

Note: Unity referral links are used in product links.

There is good and bad news with this post. Bad news first: this build was actually completed about a year and a half ago, now. So the build wont be cutting edge as of today’s tech.

However, the good news: this build was tested hard over the past year. Including playing multiple hundred hours of FFXIV at max settings, The Witcher 3: Blood and Wine expansion in its entirety on max settings, etc.

I ended up diverging from my previous post.

Here is the build I ended up with:

PCPartPicker Part List

Here is the finished product, nicely tucked in my entertainment center under my primary TV. The PS4 goes unused nowadays!

I also recommend some of the following accessories for comfortable couch gaming.

The Corsair Lapboard got 100+ hours of use recently on a playthrough of Pillars of Eternity, so I can strongly recommend that as well.

The accessories are (from left-to-right, top-to-bottom):

• Xbox Wireless Controller - Grey and Blue
• Steam Controller
• DualShock 4 - Wave Blue
• HyperX Cloud Flight Headset
• Corsair K63 Wireless Mechanical Keyboard with Lapboard
• Logitech G502 Lightspeed

Note: Amazon referral links are used in product links.

• cncf/landscape - Cloud Native Computing Foundation interactive landscape. A great resource for finding popular projects in the cloud space.
  • Also take a look at their github repository. Their included cloud native trail map is a really cool resource for anyone looking to transition into cloud technologies.
• microsoft/windows-dev-box-setup-scripts - Microsoft provided dev box setup scripts. I strongly encourage anybody on a team to leverage something like this for boostrapping developers machines. Great for onboarding! I plan on using this heavily for reference next time I need to build a dev PC.
• kubectx - This tool got mentioned to me by an engineer at work. Quickly change between contexts and namespaces. This will be a keystroke saver for those constantly switching between kubernetes contexts.

I’m a fan of strongly typed languages. So as I started my excursion into GatsbyJS, I definitely wanted to use Typescript instead of Javascript.

One of the first issues I ran across was getting strongly typed GraphQL query types in my .tsx (Typescript React) files.

Prerequisites

I used a community gatsby starter to start my project:

gatsby new gatsby-starter-typescript https://github.com/haysclark/gatsby-starter-typescript

There are other starters for typescript, but they have quite a bit more “features”. I wanted to learn a bit about GatsbyJS myself, so I started with a minimal project.

Using gql-gen to generate type files

After some investigation, it appeared the recommended way for strongly-typing your GraphQL query models, was to generate types using the gql-gen tool.

Following the graphql-code-generator installation docs, I installed a few dev dependencies into my project:

npm install --save-dev graphql-code-generator graphql
npm install --save-dev graphql-codegen-typescript-template

Now, the way gql-gen works is by analyzing a schema. This can be done a couple of different ways, either by passing a json schema file on the command line, or by passing a graphql server endpoint to the tool.

It feels like a chicken-egg scenario, but I chose to go ahead and pass the GatsbyJS hosted graphql endpoint to the gql-gen tool.

You can do so by serving up your GatsbyJS site, e.g. gatsby develop, and using the http://localhost:8000/___graphql endpoint as your source:

gql-gen --schema http://localhost:8000/___graphql  --template graphql-codegen-typescript-template --out ./src/graphql.d.ts \"./src/**/*.graphql\"

As you can see here, I’m outputting my type definitions to /src/graphql.d.ts.

Using the generated types in your components

From here, it’s pretty simple to import the types into your React components:

import { MyType } from '../graphql';

Now you have strongly typed models in your Typescript React components!

interface IndexPageProps {
  theme: Theme;
  data: {
    site: {
      siteMetadata: {
        title: string,
      },
    },
    myData: MyType,
  };
}

export default class IndexPage extends React.Component<IndexPageProps, {}> {
  public render() {
    const { title } = this.props.data.site.siteMetadata;
    return (
      <Layout>
        <ResponsiveDrawer theme={theme} data={this.props.data.myData} />
      </Layout>
    );
  }
}

I’ve tried quite a few developer podcasts, and I’ve finally wittled down to a few that I consider excellent.

1. Software Engineering Radio - This one sounds generic, but it has actually grown into a favorite of mine. The hosts usually ask great questions, and the guests always seem to be capable enough of getting into some really good technical discussions. Highly recommend this podcast.

2. Changelog - This is a podcast focused on open-source development. I usually enjoy the topics quite a bit. Every now and then I’ll skip a show though, when the topics get too “high-level.”

3. .NET Rocks - Great for keeping up with the .NET ecosystem. They have the clout to get some heavy-hitters in here. Guests have included Mads Torgerson, Scott Guthrie, Eric Lippert, and more. As with Changelog, from time-to-time I skip an episode of this, as they can get a little off topic.

4. RunAs Radio - Ops/DevOps in the Microsoft ecosystem. Has some good guests and topics on occasion, but I skip many along the way. This one is in danger of dropping off my list, but still gets a mention here because there are still gems that pop up here.

• GatsbyJS - After listening to the interview on Changelog podcast, episode #306, it has my interest piqued. I might try it out for some personal projects.
• A couple of maven plugins I’m exploring to improve my personal workflow:
  • dockerfile-maven - From spotify, can be used to set up targets to build/deploy docker containers from Dockerfiles in your modules.
  • fabric8-maven-plugin - Seems a little more “full-featured” than dockerfile-maven. I have yet to fully dig in on this one.
• commandline parser - A commandline parser for .NET.

I know this is essentially an “overpriced” console, but I enjoy it, so leave me alone.

Here was my first stab at a build, with about as high end stuff as I could pick:

PCPartPicker part list / Price breakdown by merchant

I then started reading a bit about small-form factor builds, and thought I might be able to get away with something more built around the Thermaltake Core V21, with a GTX mini instead of a full size.

I’m still very much is “design” mode now, while I’m saving up my budget to afford it.

I’ll post more as I progress and settle on a build.

• How to create a fluent interface in C# - Cool blog post about creating fluent interfaces in C#.
• azure-service-bus-dotnet - Not new, but with 3.1.0, a new ManagementClient is included.
• Lean ASP.NET Core 2.1 – manually setup a Razor Pages project with Bootstrap, NPM and webpack - Found this article for setting up webpack with ASP.NET core. It proved useful in a project I was working on.

Bear with me as I am reintroducing myself to Java at the moment, so some of the things mentioned here may be common knowledge.

• Hystrix - Obviously, this thing has been around for a while. I fully understand I’m late to the party on this one. Ironically enough, I was introduced to this while listening to a .NET podcast (.NET Rocks #1556) about Polly. I’ve used Polly in the past, but not Hystrix… yet.
• jekyll-sitemap - Planning to start using this on my website to auto-generate a compliant sitemap.
• hydeout - The theme I’m now using for this site.
• MacOS bootstrap projects. These projects made it easy for me to bootstrap my new macbook. I took some ideas from these and generated my own reusable boostrap script:
  • macOS-boostrap
  • laptop