This was a different use case than that for projects I had forked from other GitHub users which were always meant to remain strongly tied to the original repository and were as simple as clicking the Fork button in the top right of the project’s GitHub page as shown in the menu below.

Feature branching would be the way to go here if testing something new for my own repo so GitHub didn’t provide a “native” way of forking a repository in my own personal repository back into a new repo in that same user account, unless the destination repository is part of an organisational account’s listing as shown in the screenshot below.

Because in this case this is potentially an entirely new project and not just a feature, this could be a candidate for the GitHub Template repository option and exploring that feature. GitHub does a great job distinguishing between the differences between forking and templating behaviors on its platform

So this seemed like a good option to me, but I also wanted to keep one benefit of a fork, which is the ability to sync my main branch with the latest main branch in the source repo by having an upstream remote and using git merge upstream/main when appropriate to pull those changes into my forked project until this new project was ready to stand and evolve on its own. I also thought learning some of the steps to achieve my goal in a less automated manner would give me an appreciation for this feature when I looked to solve this problem again in future.

Before we get to the solution, some background for those not so familiar with how Git and GitHub work. Git uses the concepts of remotes for synchronising between your copy of a repository on a local disk and your centralised storage location. Usually with services like GitHub you always have one remote called origin which is pointing to the source URL you have cloned your local repository from. This allows you to get new commits to the remote branch you are working within using the git pull command and also to sync your local changes to the remote repository when you do a git push command.

If you fork a project and want to use the forking workflow technique you actually are adding a 2nd remote origin URL that you wish to synchronise with when changes are made to it. Git doesn’t actually have a fork command because what you are doing when you fork in GitHub is basically cloning the remote repository from the original location into your own location, and then resetting the origin to your new location. GitHub does some magic under the hood to keep track of where the original location was so if you make a change that’s particularly interesting to the original repository’s owners, you can open a PR (pull request) to start the process of having those changes integrated back to the main project.

So our manual steps will simulate what “template” repositories in GitHub are doing when you utilise them to generate a new repository within the same user account. At the end of this approach you may choose to use the forking workflow technique once more to keep in sync with changes to your source repository for some time.

Note: If you’re not starting a new project separate from your original project, feature branching is probably a better strategy here than forking if you own the repo.

1. From the GitHub website, create your new repository with the target name you want to use. An example screenshot of this page is below

2. From your local. terminal or command prompt, clone your source repository into a new folder on your local disk that would be the intended target name of your new project. E.g. git clone https://github.com/user/sourcerepo targetrepo

3. We are now going to change the origin to point to my target repository location. From the terminal or command prompt first remove the origin remote using

git remote remove origin

And then add it back using the newly created repo’s URL

git remote add origin https://github.com/user/targetrepo

We set the upstream target for the main branch and push our cloned contents to that new repo instead

git push --set-upstream origin main

And that’s it. You can now safely experiment in what is essentially a fork of your original repo within your own account. If you wanted to keep the original repo as an upstream remote you can also do that simply with

git remote add upstream https://github.com/user/sourcerepo 

Note the caveat with this approach is there’s no ties between the upstream and origin remotes recorded within GitHub itself so pushing back changes may be a little more manual as well as the “magic” GitHub usually does to keep the association between the two projects to allow the standard fork and PR workflow to be available didn’t happen in this case. To push a change back to the source repository, you would first push these changes to a branch on the source repository and then follow the pull-request workflow in GitHub for that source repository to get the changes merged into the main branch. You may also need to cherry-pick your commits with this approach since these are now essentiall two different projects so not every change in one is applicable to the other.

I hope you found this useful, if so feel free to drop a comment below or on Twitter to me about it. Happy hacking!

1. For the backend API, written using NestJS. I chose this since I am also learning this framework and really liking its use of key enterprise software design patterns I’ve used in the past in C# (my day-job language) with great success. There is a learning course available for purchase created by the author of NestJS, Kamil Myśliwiec that I have been using as my guide. I highly recommend it as it is very nicely done, and is a great fun way to both learn and give some financial support back to the creators for such a well put-together Javascript framework.
2. For a frontend web application to produce the visual part of the data the API would be providing, I have mostly been using React, and more recently Blazor to build some work based applications, but I wanted to challenge myself to learn Angular in anger for this task as I keep seeking to expand my experiences with new JS frameworks and libraries, and given that it was still Javascript and that NestJS, which I had gotten into a bit already learning thru the author’s course, was inspired by Angular patterns I took a gamble that the learning curve wouldn’t be too high to get productive with it in a few days.

I also took this challenge to also educate myself on mapping data and terminologies, and in doing so ended up using the popular LeafletJS library to render the map data which I sent from the API as GeoJSON, a popular standard for a set of data structures used for handling geographic data. One excellent resource for tackling the learning curve was this awesome series of articles by Chris Engelsma, which gave me my sample base of Angular/Leaflet front end code after following the tutorial series to start to customise my own app with.

While it’s still early days, and I probably broke some rules for “good” Angular code, I am hoping with time to write more about the experience as I push thru changes and filter into future blog posts the edits to the README file in each that has my occasional notes on interesting steps and learnings. Hope you find the code an interesting read yourself!

Reasoning for this: Microsoft’s own documentation for getting started with Fabric and React using CRA required you to clone a repository, which means you then have to modify git settings to check it into your own git repository. This isn’t the best approach given how easy it is now to setup a template for CRA.

This template allows you to just instead type npx create-react-app --template ts-fabric inside your own git repository to get started with a Fabric enabled React application

Wishful thinking: Hopefully someone among my old cohorts at Microsoft sees this and adopts the package/code into their documentation for getting started, since it really is a better approach I think that what the documentation recommends, unfortunately I couldn’t find a quick link on their page to submit this feedback or offer it for a pull request.

The problem I was trying to solve was taking all the learnings of composing my last React application from a previous project, into any new project.

Create-react-app (CRA) already did a great job of generating the boilerplate for a new React project without the need to know the intricacies of babel, webpack and the various other bits to get a build going for a new React application. The CRA’s Typescript template allows Typescript to be nicely integrated as part of the boilerplate code it generates.

This great article then basically showed me how to package this all up into a template that could be published in npm’s public repository that I could then call for any new project. Pretty sweet. Hopefully others find it useful too. There’s also good official documentation about creating custom CRA templates.

My modifications to date include:

1. Adding moment (for handling date/times properly)
2. Adding antd (The Ant Design System, which gives me a rich set of useful UI components)
3. Adding react-router-dom (which is the usual way to go about doing routing, and I’m not geek enough yet to have an opinion on any others)

You can check out my published package cra-template-typescript-redditech and give me some feedback if there’s something you see I can add to help make it better if you’re so inclined.

Side note: After the project was delivered, while deep diving behind CRA and parallel to publishing this npm package I also did start to delve into the build aspects that CRA hides so well to help me understand better how I’d go about doing what CRA did from scratch, and found other neat tools like parcel that could get you to running code quicker and make going down that path more fun as well. I highly recommend doing some learning spikes behind the magic of CRA and see which part of Wonderland this rabbit-hole leads you to.

Firstly, you will need an Azure account, which is free to sign up and which I believe you can get up to $100 free credit to start with when you sign up as a student. This should be enough for this task, as we will be using the “Azure Websites for Containers” feature, but note that the lowest tier hosting for this estimates costs approximately $40 USD a month based on the Azure pricing calculator. To get recurring monthly free credits the options include buying a Visual Studio subscription (which will get you at least $70 in credit a month) but I am not sure what the options are for students other than the one time free credit which expires 12 months after signup.

You will also need at least a free Dockerhub account. Docker Hub is the container hosting repository which we will reference from our Azure Website for Containers configuration to tell it where to get its Docker image from. Usually once you have installed Docker you’d be required to setup an account in Dockerhub to be able to pull images.

For learning, using the Cougar or Not repository on Github whose author deserves much credit for his work, was excellent for getting a starter Dockerfile as well as Fastai driven app since it includes the model file, although some modification to the app was needed to work with the updated Fastai libraries, the steps of which are documented in Fastai forums and in a pull request that is pending acceptance to the main branch of his repo.

Once you get this app running, it’s easy enough to rewrite the code bits in cougar.py for your own model once you’ve downloaded the model file (usually a .pth extension file) from the server you trained the model on. My fork of Cougar or Not has my modified code for the hummingbird classifier if you want to take a look at just how simple that is to learn, as I didn’t use python or Starlette until recently myself.

So with infrastructure done, let’s take a look at the technical bits. If you’re familiar with Docker, great! If you’re like me and know it but only used it passively and locally, the documentation page gave me the exact commands I needed to build and run the Dockerfile on my local machine without issue and publish it to my Dockerhub repository.

Assuming you have Docker installed (if on Windows PC check here) locally, from a terminal (or command prompt) in the folder for your app you build the .Dockerfile using

docker build -t <imageName> .

and can then run the image locally using

docker run -p 4000:8008 <imageName>

to test and make sure all our custom bits are working (the app runs on port 8008, but the mapping above lets you run on http://localhost:4000).

I then logged in to Dockerhub with

docker login

and after customising the running app for my model I then tagged it with my proposed repository image name with

docker tag image username/repository:tag

so in my case this was docker tag hummingbird nissan/fastai-hummingbird-classifier

before publishing it to Docker Hub with

docker push username/repository:tag

So with the Docker part completed, I then logged in to the Azure portal and created a new Azure Website for Containers app.

There are some bits to configure, like configuring the URL (<name>.azurewebsites.net) and choosing the container type (Linux) but there are a few key steps here is to get it working with your Dockerhub published container and to keep it on the lowest priced tier so you don’t burn out your credits.

The first step is to expand the “App Service plan/location” setting and create a new App Service plan in the wizard settings that use the Dev/Test workload settings, and not the default plan which uses a Premium (aka higher cost) subscription which you don’t need for testing. I selected the B1 plan, unfortunately there are no “free” website app plans for Linux containers but this is the cheapest I identified.

With this set, we look at the Configure Container screen and point it to our Docker Hub published image.

Then we click Apply and OK to complete the creation of our new Azure Web App for Containers app. After a few minutes it should be up and running, but remember the image file is about 750MB so it will take a little while after Azure indicates it completed creation and publishing of the app URL for Azure to pull in the container image and actually start it running.

You can check the log file in the Azure portal to verify your container pull has completed and is loaded before trying to load the site.

You should then have your container running inside the Azure URL you specified.

If you want to do more advanced setups there’s sufficient documentation on using Azure for setting up a DevOps pipeline  and other production-level tips as well. Happy hacking!

The problem was (as usual) data, since finding such a specialised collection of data would mean curating these manually, and even then, the dataset was nowhere large enough to work with Deep Learning’s large dataset requirements for highly successful classifiers.

However, in Lesson 2 Jeremy introduced a downloads notebook, with a very quick method for building specialised image datasets (legally) using Google Image Search. So with this problem solved, I adapted the sample notebook initially for just 3 species and was getting about 25% error rate. This was a little high, but was about the same when compared to my results in a notebook using the Birds Species dataset so still I thought things were looking promising.
However this error rate got worse to about 37% when I was up to 9 species. This notebook shows this run with unpruned data from Google for hummingbird species.
An exploration of the data showed that the errors were in the images Google was retrieving. It was not that these images were not hummingbird images, but that the wrong species type was being retrieved from Google Images for the keyword searched.

The Lesson 2 notebook also introduced a helpful FileDelete tool for pruning unwanted images out of the Google retrieved data, but this wasn’t quite apt for pruning in this case as it only showed the image, not how it was classified, so a manual pruning step was needed.
Once the data was pruned, I also sub-divided species into male and females for some species where there were clear distinguishing characteristics between the two genders. So I ended up with 14 categories with pruned data and got back to about 25% error rate. This notebook shows pruned data with 14 categories of hummingbird by species and in some cases gender.
After seeing @simonw post and exploring his source code I pushed my own model into a similar docker image and deployed it to an azure website at https://hummingbirds.azurewebsites.net/ if anyone wants to try it out for themselves.
Hopefully as I explore more I can pretty up the UI for results a bit, and add the remaining species as I build the pruned training dataset over time.
Thanks to @sparalic for inspiring me to have enough confidence to share my work too as she shared hers.

After lesson 1, I looked at the Datasets built into Fast.ai now, and decided to learn by experimenting with the bird species dataset and attempting to change Lesson 1’s notebook to work with it, since it was a similar image classification exercise.

My Key Takeaways:

• The bird species data wasn’t in quite the same structure as the Pet breeds in the lesson 1 notebook, so I learnt quite a bit thru trial and error about manipulating data paths in Python to make it work, so definitely my Python aptitude is improving from this exercise. Google helped tremendously with answering questions I had no answers to when tackling the data preparation challenges.
• I always value the “figuring it out on my own” first approach, but there was at least equal value found from sharing my work in the Fast.ai forums after completing. I found at least 2 other fellow learners who had taken on the same challenge I had with the same birds dataset, who got similar results to mine. This firstly made me more confident I had taken at least a good approach to analysis as those who also shared their notebooks. Additionally,  in reviewing their shared notebooks and recognising the divergence in our approaches, it furthered my learning of approaches in how they both prepared the data and applied the Fast.ai library.
• Finally, one unexpected and delightful outcome of participating and reviewing the forums is that I found a fellow Trinidadian also on the MOOC half a world away, who shared work of her own on a very Trinidad-specific problem set in image classification of masqueraders vs regular people. This got mentioned by the course teacher Jeremy in his 2nd lesson, so was a small moment of civic pride for me (and hopefully for the author as well) and is giving me confidence to tackle a similar problem-space with local (Trinidad) application just to see how far I can get.

In summary, reusing the lesson notebook with a new dataset was definitely challenging, and more than once I stopped in frustration, but came back and started again with baby steps towards completion. Once I got thru understanding how to get done what I set out to do though, and interacting with the forum community once I did, it really helped alot with solidifying my understanding of both Python data manipulation techniques and of using the Fast.ai library’s components more effectively for new problem sets.

The README has links to the gist files I kept track of changes or new files required as I learnt, and that can be explored by others as well to see how it was all put together. Direct link to reddi-dotnet-react-app here

I welcome any feedback from the community on it.