Forem: Jeremy Ong

C++ Neural Network in a Weekend

Jeremy Ong — Tue, 29 Sep 2020 14:18:21 +0000

There are tons of ML/AI frameworks to choose from right now (Tensorflow, Keras, Pytorch, etc). However, sometimes, building things completely from scratch is still the best way to learn how something works. To help people seeking to to this, I created a neural network in a weekend in C++ without any external dependencies. No matrix libraries, no linear algebra subroutines, nada, zilch.

The code for the repository is here. I also wrote a paper tutorial walking through the math (the derivations) and the implementation hosted in the same repository here. The paper is... a bit on the long side at 42 pages, but it's meant to be entirely self-contained. Again, from scratch!

In addition, the code is pretty heavily annotated with comments, so should hopefully be easy to following along, but please leave a question/comment if you get stuck. Happy hacking!

Recommendations for Aspiring Graphics Engineers

Jeremy Ong — Sun, 27 Sep 2020 20:28:33 +0000

At the start of 2020, I wrote this twitter thread on recommendations for engineers that are self-studying to get into graphics engineering. I decided to extract the contents of that thread here, with additional exposition for the dev.to community.

What is a graphics/rendering engineer?

Most of my followers on twitter are already graphics practitioners or on their way to becoming one, but the demographic here isn't skewed in such a way, so it makes sense to describe graphics engineering a bit more.

Graphics engineers are typically found in the games and film industry, although you'll find them in all sorts of nooks within the industry (automotive, CAD software, research labs, etc). If I had to summarize a graphics programmer's job, it's to take a scene description and produce a render. By a "scene description," what I mean is a (potentially huge) data structure describing all the geometry, skeletons, particles, terrain, atmospheric properties, in the environment in addition to all the "material data" which describes how all the aforementioned objects respond to light. Furthermore, the scene description will contain a bunch of lighting information (how many lights where, which ones cast shadows, what is the range of each light's influence, what does the skybox look like, etc). These two chunks of data (materials in the scene, and lights in the scene) dictate what is "seen" by a virtual camera used to render the scene to a monitor, image, VR goggles, or what have you.

To produce an image like the above, a ton of things are happening. First, every object pose (aka, position + orientation) must be transposed to the same "view space" of the camera. This information tells us where in the frame the object should be, and how far away from the camera it is. This same transformation needs to occur for every light in the scene as well. The crucial piece of information produced by these transforms is "occlusion" information. When an object A is between a point and another object B, we say that B is occluded by A. If the occluder is occluding light, the object behind the occluder is in shadow. If the occluder is between the object and the camera, the object occluded will not be directly visible in full.

After the geometrical information is processed (either via ray tracing, rasterization, or some other technique), the next step is lighting. Lighting is a huge topic, and it would be impossible to cover every aspect of lighting. In short however, every graphics engineer is trying to solve or approximate the equation below:

That integral above needs to be solved for every pixel in the frame. What makes matters worse is that because light "bounces" off surfaces (not just mirrors, any material that isn't vantablack or a black hole will reflect light to some degree) or "refracts" through transmissive surfaces (e.g. light bending through water), the equation above is a recursive one. Solving for all inbound light impinging on a surface requires that exitant light from nearby surfaces must be solved for as well. This includes surfaces occluded from the camera! This summarizes what is known as the global illumination problem.

Finally, many graphics engineers are also concerned with the performance of their renderer. Rendering frames accurately requires a lot of computation, so rendering typically occurs on an accelerator (most commonly, the GPU). On top of having SIMD/SIMT architectures exhibiting hierarchical parallelism, GPUs have dedicated hardware for quickly performing various operations (rasterization, texture sampling, screen-space fragment derivatives, vertex attribute interpolation, etc). Using a GPU effectively also requires a sound understanding of properly utilizing a CPU. The CPU needs to "stay ahead" of the GPU to ensure the GPU always has work to do. As a result, many renderers are heavily multi-threaded and pipelined. Film rendering engineers are typically more concerned with accuracy, while game rendering engineers are typically more concerned with latency. Either way, the rendering problem is sufficiently complicated and computationally heavy that performant code is always the objective.

Why would I want to be a graphics engineer?

This is a fair question! You'll get a different answer from every graphics engineer, but my favorite aspects are the following:

Highly interdisciplinary. Graphics engineers draw wisdom and knowledge from the following fields
- Art
- Photography
- Math (Linear Algebra, Geometry, Analysis, and more)
- Computer Science
- Electrical Engineering (in particular, signals processing)
- Physics
Finding solutions to problems in graphics typically requires some degree of creativity and sophistication
What you ultimately produce is usually pretty awesome
Colleagues in the field of graphics are generally passionate about their discipline, and exceedingly fun to talk with

In addition to the above, because graphics engineers are usually hard to find, they tend to be in high demand as well.

What are important topics a graphics engineer should study?

I find I draw from the following subjects the most consistently:

Geometry (and Geometric Algebra)
- Trigonometry
- Quaternions/Dual-quaternions
- Linear transformations
Analysis
- Calculus/vector-calculus
- Approximation theory
- Statistics (Monte-Carlo, moment analysis, etc.)
Linear Algebra
- Vector spaces
- Orthogonalization
- Various decompositions (SVD, QR)
Computer Science
- Memory hierarchy (CPU and GPU cache architecture)
- Algorithms and data structures
- Compression/codecs
- Programming language that's "close to the metal" (C, C++, Rust, etc)
Specialized knowledge on tools and APIs
- Graphics APIs depending on your target platform (for me, that's D3D12, Vulkan, PS5, Nintendo Switch)
- Profilers from Nvidia/AMD
- Crash reporting tools (e.g. Nvidia's excellent Aftermath tool)
- Frame capture tools such as the amazing RenderDoc
(Some degree of) Knowledge of how Art tools work
- Depending on the specialization within graphics you choose, it can be helpful to understand how artists are producing the data you will ultimately use (and in some cases, you're the one that builds the tools). Such tools include:
- 3D Modeling software (Maya, 3DS Max, ZBrush, etc)
- Material editors (Substance, various game engines, Nvidia's MDL)
- Scene compositors (Blender, game engines, various data formats such as GLTF, Universal Scene Description, etc)
- Heightmap editors
- Animation/motion-capture (mocap) tools

YOU DO NOT NEED TO KNOW ALL OF THE ABOVE TO GET STARTED. I can't emphasize this enough. As you can see, graphics engineers will typically get exposed to reams of tools, technologies, techniques, and concepts over the course of their careers. That's part of the fun!

OK, fine, but how do I get started?

There are two general approaches to learning anything, top-down, and bottom-up. I'll address these two approaches separately, with the caveat that most people will do a combination of both simultaneously. The degree that you go top-down vs bottom-up will depend on your learning style. Personally, as an example, I tend to go as bottom-up as possible, switching over to top-down only when I get stuck or if a concept gets lost on me.

Top-down

When learning top-down, the idea is to get the broad strokes of the concept and understand what's possible, without necessarily grasping all the details about implementation as you go. Taking this route, you will generally start with an off-the-shelf engine, such as Unreal Engine, Godot, or Unity. For learning purposes, I actually suggest engines that provide source code (i.e. not Unity) because while learning with a closed source engine is possible, it's a strict disadvantage compared to learning with source available. If C++ or C# aren't your cup of tea, there are plenty of other engines to get started in your programming language of choice. Be advised, however, that most graphics engineers in the wild are C++ programmers.

After picking an engine, you should try to accomplish the following tasks:

Draw an object to the screen
Assign a material to the object to change its appearance
Change various draw parameters to affect the object's "draw mode" (e.g. transparency, emissive)
Make a custom material to color the object something simple with a custom shader
Implement a custom material that responds to a directional light (e.g. Phong Shading)
Implement a custom material that samples from a texture

After doing the above, you should at least have a sense for how more complicated lighting models might work, without necessarily understanding the underlying math and techniques associated with it.

Bottom Up

If you take the bottom up approach, this means you want to control everything from the data, to how the data is fed to the GPU as draw calls, to what the GPU does with the draw calls, to how the draws are ultimately composited to a screen or offscreen raster (e.g. image or PDF).

To go this route, I recommend starting with either D3D11 or OpenGL (or WebGL on the web, be sure not to use Safari which has a crippled WebGL implementation). There are more modern APIs, namely D3D12 and Vulkan, but these APIs are notoriously difficult to use and designed for professionals looking to eke out as much performance as possible. The higher-level APIs such as D3D11 and OpenGL provide abstractions over memory barriers, resource ref counting, and generally take care of any potential data hazards that would otherwise crash your program. To summarize the problem, imagine you allocate memory on the GPU for a texture, and then submit a draw call that uses that texture. Later, you realize you need that memory for something else. In D3D12 and Vulkan, you must ensure that the draw call that reads from that memory has finished executing on the GPU before modifying that memory. There are many ways to do this, but in D3D11/OpenGL, such concerns are off the table because the API handles the memory management for you behind the scenes.

A great tutorial for OpenGL in particular is the Learn OpenGL tutorial, which covers the entire construction of a basic renderer. When I say "basic" here, I don't mean that all the techniques are basic, just that the architecture itself is relatively basic. If you follow it end to end, you'll learn a lot of techniques such as SSAO, bloom, and more. The still below, for example, shows the image you can create with specular image based lighting (Spec IBL).

Moving past the beginner stage

You've seen homogeneous coordinates, you've seen linear algebra, perspective transforms, shadow mapping, and a number of techniques. Hopefully, at this point, you've also taken some interviews. I'm a big believer that graphics engineers will learn most of that they know on the job, so do interview early and often to try to get a foot in the door. Generally, aptitude is more heavily weighed over experience in a graphics engineering interview, especially for a more entry level position.

From there, how do you progress to be a senior or lead graphics engineer? Here's a list of some tips I've compiled over the years.

Start avoiding commercial engines and frameworks in your own experimentation. This gets you away from the "magic" of how things happen and forces you to learn it from the ground up.
Expect to have 3 projects just generally floating in the background at once. A prototyping engine for trying out new ideas, an unbiased path-tracing engine (follow the PBR book to get started here) useful for validating results, and a "production engine" where you try to push perf to the limits.
Continue studying linear algebra, geometric algebra, calculus, fourier/harmonic analysis, and any other math topics as they arise in your work
Pay attention to data structures, particularly acceleration structures but also understand the importance of proper I-cache/D-cache utilization, branching effects, and have a good feeling for the latencies involved
From time to time, pick a paper from ACM, Arxiv, etc that interests you and try to implement it from start to finish
If you can, publish!
Learn about compression and aliasing. Maybe write a BCn codec or a DCT or wavelet codec. Experiment with the various forms of AA and analyze their tradeoffs (MSAA, MLAA, FXAA, TXAA, etc).
Stay up to date on the tools available and what they are capable of (shader compilers, shader assembly analyzers, frame dumps, GPU crash analyzers, mesh optimizers, texture compressors, etc).
Shadow the artists you work with to understand their workflows and generate ideas on how to make things better.
Study other engines, especially from studios like idTech, Ubisoft, Blizzard, Rockstar, etc (sorry if I didn't mention your studio!). The point is to study engines that achieve something you're looking to achieve as well.

Of paramount importance is to recognize that like other highly specialized disciplines, graphics engineering isn't something you can learn in a fortnight. In fact, it's likely something you'll never stop learning about. Staying humble throughout your career, never being able to admit when you're wrong, and constantly seeking to improve are surefire ways to advance and find fulfillment while doing so.

Closing Thoughts

This post was a bit difficult to write because I had to tread the line between offering too much (which gets overwhelming fast), or offering too little, in which case a concept/term is lost on the reader. Also, there's a thin line between showing innumerable possibilities that inspire, vs showing an impossibly high mountain that crushes spirits. To all who venture down this path, welcome! It's a challenging road to be sure, but you're in very good company. Never forget that if something is challenging for you, chances are, it's challenging for others as well. Personally, I've never encountered a graphics engineer that wasn't welcoming towards questions and showing a fellow engineer the ropes. On that note, any interested would-be graphics engineers are welcome to comment with questions! I often field questions sent as DMs on twitter as well, so you're more than welcome to contact me there.

More Eyes, Plz! Hackathon entry + update

Jeremy Ong — Sat, 22 Aug 2020 19:02:53 +0000

Here are the updates made since the original progress post:

added support for bot commands, starting with the [meep close] command
the site now fetches labels created dynamically for new meep requests
the site is now responsive on mobile/tablet
meeps are only filed at most once (in the event the same commit is pushed to multiple branches)

Thanks to everyone who took it for a spin and/or submitted feedback!

My Workflow

Getting started with a new programming language or framework? Trying to learn a new paradigm like functional programming? Perhaps you're getting started with a new discipline, like compiler engineering or graphics programming? Normally, we'd learn by authoring code in a "sandbox" and see what works while following along a book or tutorial. But what if you would like some pointers or feedback from someone more experienced? Stackoverflow could work, but the site encourages questions with a high degree of specificity. You can't just ask for holistic feedback for code.

More Eyes, Plz! is a service powered by Github actions to easily crowdsource commits made to any repository. To get started simply install the meep scanner action to the repo you'd like to get feedback on, or copy the following snippet to .github/workflows/meep.yml:

name: meep_scanner
on: [push]

jobs:
  meep_scan:
    runs-on: ubuntu-latest
    steps:
    - uses: moreeyesplz/meep_scanner@master
      with:
        github-token: ${{ secrets.GITHUB_TOKEN }}

After the action is installed, simply write [meep] or [MEEP] somewhere in the commit notes. Here's an example commit message:

Shortly after, the bot will post a comment that looks like the following to the commit itself:

The commit link will also be indexed on the website and show up as follows for others to see:

Afterwards, expect to get some feedback!

When you're satisfied with the feedback, simply write [meep close] in the commit thread to unlist the meep from the database.

Submission Category:

Maintainer Must Haves

Yaml File or Link to Code

Only one repository is relevant for actually integrating with the More Eyes, Plz! service:

moreeyesplz / meep_scanner

Integrate this action into your repository to start crowdsourcing feedback for your commits!

MEEP Scanner

The MEEP Scanner is a lightweight action that integrates with the More Eyes, Plz! service. When installed in a repository, the scanner scans commit messages for the [MEEP] or [meep] string. When present, the commit becomes indexed in the MEEP database for others in the community to discover.

Note that this action only works on repositories that are public at this time. Without public visibility, outside members of the community will not be able to view your commits to provide feedback.

Usage

For each repository you wish to potentially request feedback on, please performing the following steps:

1. Add topics to your repository

Topics added help others discover your requests more easily through filters. To do this, hit the settings wheel at the top right of your repository's home page. Then, add topics that pertain to your code. This could be the programming language, a framework or library…

View on GitHub

The action that responds to the scan to write the commit comment and also file an issue to the meeps tracker is here:

moreeyesplz / meeper

Internal action which accepts meeps scanned by the meep_scanner

meeper

Internal action which accepts meeps scanned by the meep_scanner. This action is dispatched only via an API call to invoke the workflow_dispatch event.

View on GitHub

Another action is used to respond to workflow_dispatch events needed to power bot commands such as [meep close]:

moreeyesplz / themeepbot

Webhook responder for themeepbot

themeepbot

Webhook responder for themeepbot

View on GitHub

Finally, the website itself is hosted via github pages and is itself open source as well:

moreeyesplz / moreeyesplz.github.io

Public-facing website aggregating and displaying meeps

More Eyes, Plz!

A simple way to crowdsource feedback on your GitHub commits

Go To Site · Get MEEP Scanner ·
Report Bug · Request Feature

✨ About the Project
- 🧩 How does it all work?
- 🔧 Built With
🚀 Getting Started
- 🌊 Workflow
🚥 Roadmap
🤝 Contributing
☎️ Contact
📚 Resources

✨ About The Project

This is a weekend project built by Jeremy and Hannah Ong as a submission to the Dev.to's GitHub Actions Hackathon. We thought that in the spirit of Dev.to and GitHub's community, that a community-led resource to help people like myself get feedback on GitHub commits would be a great submission. It went on to win the grand prize in the "Maintainer Must-Haves" category.

This README in particular will be the main documentation that explains how all the repos within More Eyes, Plz are connected.

🧩 How Does It All Work?

…

View on GitHub

Even the deployment of the site (created via create-react-app) is automated using a workflow which may be useful to others. The code used is pasted below:

name: deploy
on: ['workflow_dispatch']

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
    - name: checkout
      uses: actions/checkout@v2
      with:
        ref: master
        fetch-depth: 0
        clean: false
    - name: cache dependencies
      id: cache
      uses: actions/cache@v2
      with:
        path: node_modules
        key: ${{ runner.os }}-${{ hashFiles('package.json') }}
    - name: install dependencies
      if: steps.cache.outputs.cache-hit != 'true'
      run: npm install
    - name: build site
      run: |
        npm run build
        git config --local user.email "bot@moreeyesplz.com"
        git config --local user.name "themeepbot"
        git checkout site
        cp -r build/* ./
        rm -rf build
        git add .
        git commit -m'Automated build'
        git push origin site

Feel free to adapt this for your needs! The only thing you would probably want to change is the identifying user.email and user.name local git config (it needs to push to the site branch).

Additional Resources / Info

This project was done in collaboration with @duchesstoffee (my wife). She did the frontend, responsible for querying the meeps database (hosted using the issue tracker of this meta repo), fetch labels, and enabling tag-based searching. The frontend is built as a single page application, using the fetch API and OAuth credentials to pull data from Github.

Here is a list of dependencies used for the frontend:

React
Material UI
Octokit Rest
- Github API v3 REST client

The backend is largely driven via actions and Github itself, with no database or dedicated servers. However, a few Google Cloud functions are used simply to proxy information in a secure manner in cases where we could not ship a developer secret (with write credentials to the meeps repo) to the client. A Google Cloud function is also used to handle the oauth redirect. Here's the code for the Oauth handling for example, which runs on vanilla nodejs with no dependencies:

const https = require('https');

const HOST = process.env.HOST;

exports.auth = (req, res) => {
    if (!req.query.code) {
        return res.sendStatus(401);
    }

    https.request({
        host: 'github.com',
        path: `/login/oauth/access_token?code=${req.query.code}&client_id=${process.env.OAUTH_ID}&client_secret=${process.env.OAUTH_SECRET}`,
        method: 'POST',
        headers: {
            Accept: 'application/json',
        }
    }, (login_res) => {
        login_res.setEncoding('utf8');
        const chunks = [];

        login_res.on('data', chunks.push);
        login_res.on('error', console.error);

        login_res.on('end', () => {
            const payload = JSON.parse(chunks.join(''));
            if (payload.error) {
                res.status(401).redirect(`${HOST}?login_failed`);
            } else {
                res.status(200).redirect(`${HOST}?access_token=${payload.access_token}&scope=${payload.scope}`);
            }
        });
    }).end();
};

Here's the code for the Google Cloud function which handles the Github Webhook and forwards it as a workflow dispatch event to themeepbot bot workflow:

const https = require('https');

exports.webhook = (req, res) => {
    // Validate github user-agent
    if (!req.headers['user-agent'].startsWith('GitHub-Hookshot')) {
        return res.sendStatus(404);
    }

    const event = req.headers['x-github-event'];
    if (!event) {
        console.error('Missing event from request payload');
        return res.sendStatus(404);
    }

    const body = JSON.stringify({
        ref: 'master',
        inputs: {
            payload: Buffer.from(JSON.stringify(req.body)).toString('base64'),
            event,
        }
    });
    const request = https.request({
        host: 'api.github.com',
        path: `/repos/moreeyesplz/themeepbot/actions/workflows/bot.yml/dispatches`,
        method: 'POST',
        headers: {
            Accept: 'application/vnd.github.v3+json',
            Authorization: `token ${process.env.GITHUB_TOKEN}`,
            'User-Agent': 'moreeyesplz',
            'Content-Type': 'application/json',
            'Content-Length': body.length,
        }
    }, (response) => {
        response.setEncoding('utf8');
        const chunks = [];
        response.on('data', (chunk) => chunks.push(chunk));
        response.on('end', () => {
            if (response.statusCode !== 204) {
                console.error(`Workflow not dispatched: ${chunks.join('')}`);
            }
            res.sendStatus(response.statusCode);
        })
    });
    request.write(body);
    request.end();
}

The main "implementation detail" here is that workflow event payloads have far more keys and nested objects than what the workflow_dispatch can receive as inputs (limit is 10). As a workaround, this event proxy simply base64 encodes the entire payload and forwards it as a single event for the downstream action to parse later. Thus, the "heavy lifting" that needs to interact with the Github APIs can be done in action-based workflows.

All the actions and workflow code are very light on dependencies, using only the actions toolkit.

Introducing MEEP: More Eyes, Plz! Testers wanted!

Jeremy Ong — Tue, 18 Aug 2020 04:20:02 +0000

Introduction

Are you starting your coding journey? Experienced but venturing into unfamiliar territory? My wife and I are pleased to show the first version of More Eyes, Plz!, a new service powered by Github Actions to crowdsource feedback, suggestions, and insight on your commits.

This is a WIP but we believe (knock on wood) that all the major components are there that it can start providing value and we can't wait to see people try it out.

How do I use it?

The only thing you need to get started is to install the MEEP scanner action into a repo. Then, all commits with [MEEP] in the commit message will be automatically indexed. Indexed MEEP requests will show up on the website where people can browse and filter for requests they can provide feedback on. To kick things off, themeepbot will write a message on your commit like so:

Please give it a try, we have C++, Javascript, Game Dev, and more volunteers ready to provide feedback :). Also, if you're willing to participate as someone who would like to provide feedback as well, that would be awesome. Keep in mind that the site works best on desktop right now. Making the site responsive for mobile/tablet is coming next.

How is feedback provided?

Github supports linking to commits directly, where you can comment on specific lines of code, or comment in the general commit thread below. Don't forget to thank people who help you out!

Why did we write it?

My wife made the brave decision to make a career switch to engineering a few months ago. She has loved dev.to as a resource ever since she started, so when we saw the hackathon announcement, we started brainstormings projects we could work on together. One observation was that the community has tons of knowledgeable and experienced engineers that are very generous with providing feedback. More Eyes, Plz! was something we created to help streamline both requesting and providing feedback.

How does it work?

Actions, actions, and more actions. More Eyes, Plz! runs almost completely off Github by leveraging actions. The data pipeline is as follows.

The MEEP Scanner runs on every push. For each commit that contains [MEEP], the commit metadata is sent to a Google Cloud Function.
The cloud function dispatches another action (called the "meeper") on a central repository, forwarding along the commit metadata as inputs by POSTing a workflow_dispatch event.
The meeper action uses Github app credentials associated with a bot we built called themeepbot. The action authors a comment on the issuing commit (from step one) and also creates an issue on the meeps repository.
The website uses the Github REST API to query and search for issues, presenting them to users in a digestible way.

All components of the service (actions, website, tracker, bot) are open-sourced for the community to learn and benefit from. Feel free to browse the moreeyesplz organization page on Github.

Please try it out and let us know what you think!

If you run into issues, please file an issue on our general issue tracker. We wrote this in a weekend, and we already have tons of ideas on where to go next (leaderboard maybe? bot commands for closing out issues?).

Appendix: More implementation details!

Using Cloud Functions

The reason we couldn't build this service entirely off of Github actions for security reasons. First, you definitely need some server-side code to run to authenticate OAuth tokens. In addition, we need to dispatch a workflow via REST API. This requires an access token with the workflow permission which we can't ship as part of the scanner or provide to users (or anyone would be able to dispatch the workflow easily). Instead of maintaining servers, we wrote extremely lightweight cloud functions to easily sit inside the GCP free tier. The bulk of the the work is done by workflows to integrate with Github's APIs (creating commit comments, issues, querying data, etc).

Using the Issue Tracker as a Database

Our favorite aspect of the design is the use of Github's fantastic issue tracker as a "database." One snag we initially ran into was that commit messages can contain arbitrary text (including unicode). This can make dealing with HTTP payload parsing being fussy (sending strings embedded in JSON payloads that contain quotation marks, braces, etc is an issue for example). The solution in a pinch is just to base64 encode the text and base64 decode it in the client. The benefit of using the issue tracker as a database is that we can easily interact with it in Github actions, which provides a robust querying interace.

Website Construction

The website is a single-page application built using TypeScript, React, and Material-UI. My wife designed and built the entire thing :). I think it's an amazing result for a weekend project considering she only started learning to code earlier this year. All data is fetched dynamically after the initial site load. Sign-in with Github is mandated to avoid rate limits hit when performing API requests without an access token. Feel free to follow the development of the website here.

Bonus: Github Workflow that Deploys the Site

The site is hosted via Github Pages. To deploy the site, we simply kickoff a workflow which is defined here. This workflow could serve as the basis of other workflows that need to accomplish something similar. Some highlights:

The site branch was created with git checkout --orphan to avoid branching off the main branch with source files
The actions/cache@v2 action is used to avoid fetching dependencies each time
The workflow commits the built artifacts to the site branch using the built-in credentials provided by actions/checkout@v2

Bot incoming!

One workflow that we want to support is easily using commands to do things like close a meep, give kudos to people that were particularly helpful, edit meep labels, and more. Please stay tuned for future updates!

Forem: Jeremy Ong

C++ Neural Network in a Weekend

Recommendations for Aspiring Graphics Engineers

What is a graphics/rendering engineer?

Why would I want to be a graphics engineer?

What are important topics a graphics engineer should study?

OK, fine, but how do I get started?

Top-down

Bottom Up

Moving past the beginner stage

Closing Thoughts

More Eyes, Plz! Hackathon entry + update

My Workflow

Submission Category:

Yaml File or Link to Code

moreeyesplz / meep_scanner

Integrate this action into your repository to start crowdsourcing feedback for your commits!

MEEP Scanner

Usage

1. Add topics to your repository

moreeyesplz / meeper

Internal action which accepts meeps scanned by the meep_scanner

meeper

moreeyesplz / themeepbot

Webhook responder for themeepbot

themeepbot

moreeyesplz / moreeyesplz.github.io

Public-facing website aggregating and displaying meeps

More Eyes, Plz!

Table of Contents

✨ About The Project

🧩 How Does It All Work?

Additional Resources / Info

Introducing MEEP: More Eyes, Plz! Testers wanted!

Introduction

How do I use it?

How is feedback provided?

Why did we write it?

How does it work?

Please try it out and let us know what you think!

Appendix: More implementation details!

Using Cloud Functions

Using the Issue Tracker as a Database

Website Construction

Bonus: Github Workflow that Deploys the Site

Bot incoming!