<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Org:jrbeverly on jrbeverly</title><link>https://workbench.jrbeverly.ca/tags/orgjrbeverly/</link><description>Recent content in Org:jrbeverly on jrbeverly</description><generator>Hugo</generator><language>en-CA</language><lastBuildDate>Thu, 19 May 2022 00:58:15 +0000</lastBuildDate><atom:link href="https://workbench.jrbeverly.ca/tags/orgjrbeverly/index.xml" rel="self" type="application/rss+xml"/><item><title>swagger-golang-bazelgen-exp</title><link>https://workbench.jrbeverly.ca/2022/05/jrbeverly-swagger-golang-bazelgen-exp/</link><pubDate>Thu, 19 May 2022 00:58:15 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2022/05/jrbeverly-swagger-golang-bazelgen-exp/</guid><description>&lt;h1 id="golang--openapi-spec"&gt;Golang &amp;amp; OpenAPI Spec&lt;/h1&gt;
&lt;p&gt;Fiddling with an idea of generating models from the OpenAPI spec for YAML.&lt;/p&gt;
&lt;h2 id="notes"&gt;Notes&lt;/h2&gt;
&lt;ul&gt;
&lt;li&gt;Bazel model works, but would want to formalize as a proper build system&lt;/li&gt;
&lt;li&gt;Model of &lt;code&gt;pkg/apis/...&lt;/code&gt; is a good direction, version selecting will need to be a thing though&lt;/li&gt;
&lt;li&gt;What about YAML Support?&lt;/li&gt;
&lt;li&gt;Is &lt;code&gt;swagger&lt;/code&gt; the expected way forward for this kind of thing?&lt;/li&gt;
&lt;li&gt;Should the generation of files be done as a &lt;code&gt;bazel run&lt;/code&gt; or a bazel build?&lt;/li&gt;
&lt;li&gt;Generation should really commit against the repository, that way we can be more confident about the code results&lt;/li&gt;
&lt;li&gt;Works much better to have all components available&lt;/li&gt;
&lt;/ul&gt;</description></item><item><title>graphql-golang-note-check</title><link>https://workbench.jrbeverly.ca/2022/05/jrbeverly-graphql-golang-note-check/</link><pubDate>Wed, 18 May 2022 23:21:25 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2022/05/jrbeverly-graphql-golang-note-check/</guid><description>&lt;h1 id="fiddling-with-gqlgen"&gt;Fiddling with gqlgen&lt;/h1&gt;
&lt;p&gt;Experimenting a bit with gqlgen for generating GraphQL code from spec.&lt;/p&gt;
&lt;h2 id="notes"&gt;Notes&lt;/h2&gt;
&lt;ul&gt;
&lt;li&gt;Would prefer to move &lt;code&gt;gqlgen.yml&lt;/code&gt; and &lt;code&gt;schema.graphql&lt;/code&gt; into a spec/ directory (or other areas)&lt;/li&gt;
&lt;li&gt;Installation method with &lt;code&gt;tools.go&lt;/code&gt; - not sure about this, static binary is preferrable for my usages&lt;/li&gt;
&lt;li&gt;Generated models are pretty solid, similar to swagger&lt;/li&gt;
&lt;li&gt;Resolvers is nice, but what about partial updates?&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;I&amp;rsquo;m not entirely sold on this pattern. Feel like I&amp;rsquo;d prefer more &lt;em&gt;flexibility&lt;/em&gt; with how the models and various components are defined. Almost interested in the idea of instead of using annotations like &lt;code&gt;json&lt;/code&gt; or &lt;code&gt;yaml&lt;/code&gt;, leveraging generated code for rendering the JSON/YAML components. Then isolating the various elements of what the system is expected to do, things like:&lt;/p&gt;</description></item><item><title>react-xstate-machines</title><link>https://workbench.jrbeverly.ca/2022/05/jrbeverly-react-xstate-machines/</link><pubDate>Wed, 18 May 2022 23:14:27 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2022/05/jrbeverly-react-xstate-machines/</guid><description>&lt;h1 id="state-machine-for-confirmation-dialog"&gt;State Machine for Confirmation Dialog&lt;/h1&gt;
&lt;p&gt;Running through the workshop example of &lt;a
 href="https://daveceddia.com/react-confirmation-modal-state-machine/" target="_blank" rel="noreferrer"&gt;Build A Confirmation Modal in React with State Machines&lt;/a&gt;
&lt;/p&gt;
&lt;h2 id="notes"&gt;Notes&lt;/h2&gt;
&lt;ul&gt;
&lt;li&gt;In principal, like the idea of representation this kinds of logic &amp;ldquo;Flows&amp;rdquo;&lt;/li&gt;
&lt;li&gt;Usage of strings for state is less than ideal, almost would want it to be objects&lt;/li&gt;
&lt;li&gt;Pattern of constructing a &amp;ldquo;flow&amp;rdquo; then making use of the &amp;ldquo;flow&amp;rdquo;&lt;/li&gt;
&lt;li&gt;Potential opportunities with systems like codegen&lt;/li&gt;
&lt;li&gt;Possible ideas for test evaluation with the states&lt;/li&gt;
&lt;li&gt;Not sure about this library, needs opportunities for &lt;em&gt;isolation&lt;/em&gt;&lt;/li&gt;
&lt;li&gt;Feels like it doesn&amp;rsquo;t fit with the View -&amp;gt; ViewModel -&amp;gt; Model concept I was thinking of for State Machines&lt;/li&gt;
&lt;li&gt;The &amp;lsquo;dispatcher&amp;rsquo; works similar to what a wrapper over &amp;ldquo;Modal&amp;rdquo; would have, what benefits does it bring?&lt;/li&gt;
&lt;li&gt;Consider looking into eventing systems instead, they seem to better encapsulate this idea without strictness of the &amp;ldquo;machine structure&amp;rdquo;&lt;/li&gt;
&lt;li&gt;Maybe this could work better when combined with message passing + code generation?&lt;/li&gt;
&lt;/ul&gt;</description></item><item><title>exp-pulumi-lambda</title><link>https://workbench.jrbeverly.ca/2022/05/jrbeverly-exp-pulumi-lambda/</link><pubDate>Wed, 18 May 2022 00:40:54 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2022/05/jrbeverly-exp-pulumi-lambda/</guid><description>&lt;h1 id="experimenting-with-pulumi"&gt;Experimenting with Pulumi&lt;/h1&gt;
&lt;p&gt;Experimenting with the pulumi examples from &lt;a
 href="https://github.com/pulumi/examples" target="_blank" rel="noreferrer"&gt;https://github.com/pulumi/examples&lt;/a&gt;
, and the options to have&lt;/p&gt;
&lt;h1 id="notes"&gt;Notes&lt;/h1&gt;
&lt;ul&gt;
&lt;li&gt;Enabling Bazel wtih this model encountered some pain points&lt;/li&gt;
&lt;li&gt;Pulumi is capable of performing operations like Docker Build / Referencing lambda binaries&lt;/li&gt;
&lt;li&gt;The change source pattern (&lt;code&gt;git.dirty, git.author, etc&lt;/code&gt;) for volatile status is a nice pattern&lt;/li&gt;
&lt;li&gt;Building of artifacts should not be the responsibility of the deployment model&lt;/li&gt;
&lt;li&gt;Pulumi takes over the &lt;em&gt;context&lt;/em&gt; element of deployments, and use that for deployments&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;Pulumi has some nice elements too it with respect to be able to use code to create the deployment, as well as a good web/console interface. However I&amp;rsquo;m not sold on the idea of these kind of &amp;ldquo;dynamic&amp;rdquo; systems, and instead prefer the style of an &lt;em&gt;application model&lt;/em&gt;. This way a series of concerns can be baked into &amp;ldquo;Configuration&amp;rdquo; that is then acted upon, similar to Terraform.&lt;/p&gt;</description></item><item><title>golang-gin-gitpod</title><link>https://workbench.jrbeverly.ca/2022/05/jrbeverly-golang-gin-gitpod/</link><pubDate>Wed, 18 May 2022 00:23:29 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2022/05/jrbeverly-golang-gin-gitpod/</guid><description>&lt;h1 id="golang-gin--gitpod"&gt;Golang Gin &amp;amp; Gitpod&lt;/h1&gt;
&lt;p&gt;Fiddling with the Dev experience of Golang gin within Gitpod&lt;/p&gt;
&lt;p&gt;Based on &lt;a
 href="https://github.com/gitpod-io/go-gin-app" target="_blank" rel="noreferrer"&gt;gitpod-io/go-gin-app&lt;/a&gt;
&lt;/p&gt;
&lt;h2 id="notes"&gt;Notes&lt;/h2&gt;
&lt;ul&gt;
&lt;li&gt;Prefer the pattern of combining this with cobra&lt;/li&gt;
&lt;li&gt;Server rendered HTML is pretty straightforward&lt;/li&gt;
&lt;li&gt;Returning simple JSON pretty straightforward&lt;/li&gt;
&lt;li&gt;Can be combined with GRPC + Proto&lt;/li&gt;
&lt;li&gt;What about swagger for generating the modules?&lt;/li&gt;
&lt;li&gt;Considerations about how to organize the elements (cli, server, routes, models, database, etc)&lt;/li&gt;
&lt;li&gt;What about logging for this?&lt;/li&gt;
&lt;li&gt;Gitpod has occassionally issues with the import of gin&lt;/li&gt;
&lt;li&gt;References for things like &lt;code&gt;templates/&lt;/code&gt; at the top level is nice&lt;/li&gt;
&lt;li&gt;Log while running is excellent&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;Overall positive.&lt;/p&gt;</description></item><item><title>reminders-miragejs</title><link>https://workbench.jrbeverly.ca/2022/05/jrbeverly-reminders-miragejs/</link><pubDate>Wed, 18 May 2022 00:07:08 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2022/05/jrbeverly-reminders-miragejs/</guid><description>&lt;h1 id="miragejs-tutorial"&gt;MirageJS Tutorial&lt;/h1&gt;
&lt;p&gt;Running through the (MirageJS Tutorial)[https://github.com/miragejs/tutorial] case&lt;/p&gt;
&lt;h2 id="notes"&gt;Notes&lt;/h2&gt;
&lt;ul&gt;
&lt;li&gt;If generated from a schema, the system is essentially
&lt;ul&gt;
&lt;li&gt;Backend (proper)&lt;/li&gt;
&lt;li&gt;Backend Mock (in-memory)&lt;/li&gt;
&lt;li&gt;Backend JS Client (proper)&lt;/li&gt;
&lt;li&gt;Backend JS Client Mock (in-memory - integrated with MirageJS)&lt;/li&gt;
&lt;/ul&gt;
&lt;/li&gt;
&lt;li&gt;How could this be integrated with code generation from a specification?&lt;/li&gt;
&lt;li&gt;Does this assist with local development?&lt;/li&gt;
&lt;li&gt;Test scenarios in an pseudo-E2E case?&lt;/li&gt;
&lt;/ul&gt;</description></item><item><title>manim-exp-video-generation</title><link>https://workbench.jrbeverly.ca/2022/05/jrbeverly-manim-exp-video-generation/</link><pubDate>Tue, 17 May 2022 02:10:19 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2022/05/jrbeverly-manim-exp-video-generation/</guid><description>&lt;h1 id="manim-experimentation-with-video-generation"&gt;MAnim Experimentation with Video Generation&lt;/h1&gt;
&lt;p&gt;Experimenting with the MAnim library for generating video animations.&lt;/p&gt;
&lt;h2 id="notes"&gt;Notes&lt;/h2&gt;
&lt;ul&gt;
&lt;li&gt;Solid library that works really well at what it does&lt;/li&gt;
&lt;li&gt;Scenes feel very &amp;ldquo;on-track&amp;rdquo; in that it is a sequence of steps one followed by the next&lt;/li&gt;
&lt;li&gt;Python allows for re-use to create common elements like an isometric file&lt;/li&gt;
&lt;li&gt;Works great for scenes where the emphasis is on the core &amp;ldquo;shapes&amp;rdquo; and animation&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;Don&amp;rsquo;t think this fits with the use-case I&amp;rsquo;m after. Would make more sense to explore as a unity &amp;ldquo;game&amp;rdquo; that is really just an interactive cutscene. As that would allow for elements of the scene to still remain dynamic (animated) while the core &amp;ldquo;state&amp;rdquo; of the animation remains at a fixed point in time.&lt;/p&gt;</description></item><item><title>react-wasm-babel</title><link>https://workbench.jrbeverly.ca/2022/05/jrbeverly-react-wasm-babel/</link><pubDate>Tue, 17 May 2022 02:05:18 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2022/05/jrbeverly-react-wasm-babel/</guid><description>&lt;h1 id="react-webpack-with-rust-webassembly"&gt;React Webpack with Rust WebAssembly&lt;/h1&gt;
&lt;p&gt;Fiddling around with an opinionated example for Webpack builds with WebAssembly.&lt;/p&gt;
&lt;p&gt;Source code for fractal is based on &lt;a
 href="https://dev.to/brightdevs/using-webassembly-with-react-1led" target="_blank" rel="noreferrer"&gt;https://dev.to/brightdevs/using-webassembly-with-react-1led&lt;/a&gt;
, and the repository templated by &lt;a
 href="https://github.com/Fallenstedt/wasm-react-webpack-template" target="_blank" rel="noreferrer"&gt;https://github.com/Fallenstedt/wasm-react-webpack-template&lt;/a&gt;
.&lt;/p&gt;
&lt;h2 id="notes"&gt;Notes&lt;/h2&gt;
&lt;ul&gt;
&lt;li&gt;WASM Build works pretty well with rust&lt;/li&gt;
&lt;li&gt;Rust is a solid option for getting webassembly integrated&lt;/li&gt;
&lt;li&gt;Golang was considered, but previous experiments weren&amp;rsquo;t as desired&lt;/li&gt;
&lt;li&gt;Makefile as an entrypoint is preferrable than using &lt;code&gt;yarn ...&lt;/code&gt;&lt;/li&gt;
&lt;li&gt;Embedding the generated packages within the front (e.g. under &lt;code&gt;pkg/&lt;/code&gt;) allows for local refs&lt;/li&gt;
&lt;li&gt;When does the build perform certain targets? E.g. resolution of paths vs copying of static files?&lt;/li&gt;
&lt;li&gt;Searching for options of individual target execution didn&amp;rsquo;t yield much (using wrong search terms?)&lt;/li&gt;
&lt;li&gt;Webpacks plugin model isn&amp;rsquo;t really the desired execution model, prefer graph-driven like buck/bazel&lt;/li&gt;
&lt;li&gt;Webpack plugin dumping the files just by directory path isn&amp;rsquo;t ideal, would prefer to ref (e.g. &lt;code&gt;//pkg/fractal&lt;/code&gt;)&lt;/li&gt;
&lt;li&gt;Loading WebAssembly requires a bit of pre-amble, could probably be made into a &lt;code&gt;&amp;lt;project&amp;gt;-commons&lt;/code&gt; for UIs responsible for loading it&lt;/li&gt;
&lt;li&gt;Usages of them are pretty nice, opportunities for generated API/Schemas/State Machines/State Models&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;I&amp;rsquo;m not sure on this one. I get the benefits that come with the webpack ecosystem, but had multiple issues with the way its goes about it in comparison to patterns like Bazel/Buck. I like this pattern more for combining various languages to create the final result, such as having a rust library for certain functions or components. Splitting it away from the frontend makes it so they can be designed in more of a &amp;ldquo;unit-test&amp;rdquo; way. Possible options might be to encode a state machine within one of these libraries, then have the web interface act on this, like a &lt;code&gt;View =&amp;gt; ViewModel =&amp;gt; {Model}&lt;/code&gt; where the &lt;code&gt;ViewModel&lt;/code&gt; performs queries into the state machine &lt;code&gt;{Model}&lt;/code&gt;.&lt;/p&gt;</description></item><item><title>vuln-disclosure-policy</title><link>https://workbench.jrbeverly.ca/2022/05/jrbeverly-vuln-disclosure-policy/</link><pubDate>Fri, 13 May 2022 03:25:29 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2022/05/jrbeverly-vuln-disclosure-policy/</guid><description>&lt;h1 id="vulnerability-disclosure-policy-from-dioterms"&gt;Vulnerability Disclosure Policy from Dioterms&lt;/h1&gt;
&lt;p&gt;Exploring leveraging &lt;a
 href="https://github.com/disclose/dioterms" target="_blank" rel="noreferrer"&gt;dioterms&lt;/a&gt;
 and &lt;a
 href="https://policymaker.disclose.io/policymaker" target="_blank" rel="noreferrer"&gt;policymaker&lt;/a&gt;
 for creating vulnerability disclore policies for a website.&lt;/p&gt;
&lt;h2 id="notes"&gt;Notes&lt;/h2&gt;
&lt;ul&gt;
&lt;li&gt;DNS is related for the deployment of the website (&lt;code&gt;_security&lt;/code&gt;)&lt;/li&gt;
&lt;li&gt;Entry within the &lt;code&gt;/.well-known/&lt;/code&gt; root of the domain (&lt;code&gt;example.com/.well-known/security.txt&lt;/code&gt;)&lt;/li&gt;
&lt;li&gt;Security entry for the domain (&lt;code&gt;example.com/security&lt;/code&gt;)&lt;/li&gt;
&lt;li&gt;If the application is located within &lt;code&gt;example.com/app/...&lt;/code&gt; (e.g. &lt;code&gt;index.html&lt;/code&gt;), then the top level domain elements can be &amp;ldquo;procedural&amp;rdquo;&lt;/li&gt;
&lt;li&gt;Construct the webpage into a bundle (&lt;code&gt;website.wbn&lt;/code&gt;), publish it to the &amp;ldquo;deployer&amp;rdquo;, which can then handle the top level elements&lt;/li&gt;
&lt;li&gt;References can still exist within the app (&lt;code&gt;/security&lt;/code&gt;, &lt;code&gt;/.well-known/...&lt;/code&gt;), known to the website manifest&lt;/li&gt;
&lt;li&gt;Website manifest allow it to enforce expectations about required top-level components&lt;/li&gt;
&lt;li&gt;Distributable/Sharable webpages can combine/merge these components (e.g. &lt;code&gt;website.wbn, website.manifest, website.policy&lt;/code&gt;) with organization (or overwrite)&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;Acknowledgements:&lt;/p&gt;</description></item><item><title>bazel-terraform-conftest-experiments</title><link>https://workbench.jrbeverly.ca/2022/05/jrbeverly-bazel-terraform-conftest-experiments/</link><pubDate>Wed, 11 May 2022 02:21:49 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2022/05/jrbeverly-bazel-terraform-conftest-experiments/</guid><description>&lt;h1 id="experimenting-with-conftest-terraform--bazel"&gt;Experimenting with ConfTest, Terraform &amp;amp; Bazel&lt;/h1&gt;
&lt;p&gt;Experimenting with using Bazel to handle the build &amp;amp; execution of Terraform files, while providing means of writing tests against the terraform with conftest. Fiddling with the idea of having local tests against the configuration, as well as tests against the terraform plan.&lt;/p&gt;</description></item><item><title>asdf</title><link>https://workbench.jrbeverly.ca/2022/05/jrbeverly-asdf/</link><pubDate>Tue, 10 May 2022 22:33:19 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2022/05/jrbeverly-asdf/</guid><description>&lt;h1 id="asdf-lint-tests"&gt;asdf &lt;a
 href="https://github.com/asdf-vm/asdf/actions/workflows/lint.yml" target="_blank" rel="noreferrer"&gt;&lt;figure class="content-image"&gt;
 &lt;img
 src="https://github.com/asdf-vm/asdf/actions/workflows/lint.yml/badge.svg"
 alt="Lint"
 loading="lazy"/&gt;&lt;/figure&gt;
&lt;/a&gt;
 &lt;a
 href="https://github.com/asdf-vm/asdf/actions/workflows/tests.yml" target="_blank" rel="noreferrer"&gt;&lt;figure class="content-image"&gt;
 &lt;img
 src="https://github.com/asdf-vm/asdf/actions/workflows/tests.yml/badge.svg"
 alt="Tests"
 loading="lazy"/&gt;&lt;/figure&gt;
&lt;/a&gt;
&lt;/h1&gt;
&lt;p&gt;&lt;strong&gt;Manage multiple runtime versions with a single CLI tool, extendable via plugins&lt;/strong&gt; - &lt;a
 href="https://asdf-vm.github.io/asdf/" target="_blank" rel="noreferrer"&gt;docs at asdf-vm.com&lt;/a&gt;
&lt;/p&gt;
&lt;p&gt;asdf is a CLI tool that can manage multiple language runtime versions on a per-project basis. It is like &lt;code&gt;gvm&lt;/code&gt;, &lt;code&gt;nvm&lt;/code&gt;, &lt;code&gt;rbenv&lt;/code&gt; &amp;amp; &lt;code&gt;pyenv&lt;/code&gt; (and more) all in one! Simply install your language&amp;rsquo;s plugin!&lt;/p&gt;</description></item><item><title>julia-with-jupyter-notebook</title><link>https://workbench.jrbeverly.ca/2022/04/jrbeverly-julia-with-jupyter-notebook/</link><pubDate>Thu, 07 Apr 2022 03:14:33 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2022/04/jrbeverly-julia-with-jupyter-notebook/</guid><description>&lt;h1 id="julia-jupyter-notebook"&gt;Julia Jupyter Notebook&lt;/h1&gt;
&lt;p&gt;Experiments with working with Julia &amp;amp; Jupyter Notebooks.&lt;/p&gt;
&lt;h2 id="notes"&gt;Notes&lt;/h2&gt;
&lt;ul&gt;
&lt;li&gt;Installation of Jupyter, Conda + Julia (+ packages) onto a gitpod image&lt;/li&gt;
&lt;li&gt;Makefile for common actions working with the notebooks&lt;/li&gt;
&lt;li&gt;Validating some basic cases working with Julia for generating plots &amp;amp; other bits for the visualization&lt;/li&gt;
&lt;/ul&gt;</description></item><item><title>gitpod-jupyter-notebook</title><link>https://workbench.jrbeverly.ca/2022/03/jrbeverly-gitpod-jupyter-notebook/</link><pubDate>Thu, 17 Mar 2022 23:41:20 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2022/03/jrbeverly-gitpod-jupyter-notebook/</guid><description>&lt;h1 id="gitpod-jupyter-notebook"&gt;GitPod Jupyter Notebook&lt;/h1&gt;
&lt;p&gt;Validating working with Jupyter notebooks in a GitPod environments&lt;/p&gt;
&lt;h2 id="notes"&gt;Notes&lt;/h2&gt;
&lt;ul&gt;
&lt;li&gt;Support for preview or open in browser mode&lt;/li&gt;
&lt;li&gt;Initial provisioning of the image takes a bit, pre-baked likely would help in this area&lt;/li&gt;
&lt;li&gt;Jupyter lab is another option&lt;/li&gt;
&lt;li&gt;Makefile is a good option for acting as an entrypoint for common commands&lt;/li&gt;
&lt;li&gt;Outstanding questions still exist for multi-notebook repositories like the learning repo&lt;/li&gt;
&lt;/ul&gt;</description></item><item><title>pushgateway-compose-setup</title><link>https://workbench.jrbeverly.ca/2022/03/jrbeverly-pushgateway-compose-setup/</link><pubDate>Tue, 15 Mar 2022 22:33:21 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2022/03/jrbeverly-pushgateway-compose-setup/</guid><description>&lt;h1 id="pushgateway-compose-setup"&gt;Pushgateway Compose Setup&lt;/h1&gt;
&lt;p&gt;Simple code setup for spinning up Pushgateway, Prometheus &amp;amp; Grafana for validating lifecycle pushgateway metrrics.&lt;/p&gt;
&lt;h2 id="notes"&gt;Notes&lt;/h2&gt;
&lt;ul&gt;
&lt;li&gt;Metrics published to pushgateway are collected by Prometheus&lt;/li&gt;
&lt;li&gt;Prometheus is enabled in Grafana for queries&lt;/li&gt;
&lt;li&gt;Grafana datasources &amp;amp; dashboards are configured from the provisioning directory&lt;/li&gt;
&lt;li&gt;The script &lt;code&gt;publish.sh&lt;/code&gt; can be used to publish the metrics into the system&lt;/li&gt;
&lt;li&gt;Dashboards in &lt;code&gt;grafana/dashboards&lt;/code&gt; can be configured with other tools for construction&lt;/li&gt;
&lt;li&gt;Dashboards could be standardized, then shared into other sources&lt;/li&gt;
&lt;li&gt;Tools can be configured for publishing in these scenarios&lt;/li&gt;
&lt;/ul&gt;</description></item><item><title>aws-exp-organizations-policy</title><link>https://workbench.jrbeverly.ca/2022/03/jrbeverly-aws-exp-organizations-policy/</link><pubDate>Sun, 06 Mar 2022 21:32:19 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2022/03/jrbeverly-aws-exp-organizations-policy/</guid><description>&lt;h1 id="aws-organization-structure-experiments---mirrored-organizations"&gt;AWS Organization Structure Experiments - Mirrored Organizations&lt;/h1&gt;
&lt;p&gt;Experiments with AWS Organization structure and potential SCP policies.&lt;/p&gt;
&lt;h2 id="notes"&gt;Notes&lt;/h2&gt;
&lt;ul&gt;
&lt;li&gt;The entire organization unit hierarchy shouldn&amp;rsquo;t be a single entity for mirroring. Makes it difficult to evaluate in &amp;ldquo;isolation&amp;rdquo;&lt;/li&gt;
&lt;li&gt;Entire organization mirrors can work with the SCPs, but internal permissions (e.g. S3 Bucket) still might have issues&lt;/li&gt;
&lt;li&gt;Organizations should include a uniqueness component to allow for constructing a new version (&amp;amp; prototyping)&lt;/li&gt;
&lt;li&gt;SCPs seem like they would benefit in cases where there is a sort of &amp;ldquo;State machine&amp;rdquo; in the SCP&lt;/li&gt;
&lt;li&gt;State machine examples are &amp;ldquo;During provisioning of account, need to create IAM Users, but from then on no users should be created&amp;rdquo;&lt;/li&gt;
&lt;li&gt;Account boundaries for services as a way of strictly locking things makes it easier to have &lt;code&gt;DenyKMS&lt;/code&gt; and other such policies&lt;/li&gt;
&lt;li&gt;Region denies only apply after provisioning, as we need to purge the &amp;ldquo;default VPCs&amp;rdquo; created when an AWS Account is created (+ any other &amp;ldquo;default&amp;rdquo; resources)&lt;/li&gt;
&lt;li&gt;AWS Password Policy / AWS IAM Account Name / Etc are all good examples of something that should only need to be provisioned &amp;ldquo;once&amp;rdquo;&lt;/li&gt;
&lt;li&gt;SCPs give a potential idea for the concept of &amp;ldquo;Immutable AWS Account Infrastructure&amp;rdquo;, that require you to create a new AWS Account (+ migrate resources) rather than edit them&lt;/li&gt;
&lt;li&gt;Sandbox/Staging organizations can contain the developer workloads that are for sandbox/development&lt;/li&gt;
&lt;li&gt;Developer workloads should be contained within accoounts that can be created/decommissioned on a release schedule (see ubuntu - Bionic Beaver, Focal Fossa, Xenial Xerus)&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;More investigation is needed into this idea, as the exact &amp;ldquo;concern&amp;rdquo; that this kind of structure &amp;amp; SCP policy layout will handle is kind of vague. Although grouping AWS Accounts and associating tags with them can be useful for things like data residency / storage compliance, its not immediately clear how this design maps to the &amp;ldquo;problem&amp;rdquo; itself.&lt;/p&gt;</description></item><item><title>github-pullthrough-mirror</title><link>https://workbench.jrbeverly.ca/2022/03/jrbeverly-github-pullthrough-mirror/</link><pubDate>Fri, 04 Mar 2022 04:32:17 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2022/03/jrbeverly-github-pullthrough-mirror/</guid><description>&lt;h1 id="release-mirror-for-github-releases"&gt;Release Mirror for GitHub Releases&lt;/h1&gt;
&lt;p&gt;Lightweight experiment for mirroring GitHub releases into a file store system like Minio or AWS S3.&lt;/p&gt;
&lt;h2 id="getting-started"&gt;Getting Started&lt;/h2&gt;
&lt;h3 id="packages"&gt;packages/&lt;/h3&gt;
&lt;p&gt;Contains the tool definition files for each of the mirror repositories (&lt;code&gt;tool.ini&lt;/code&gt;), and the computed checksums for the downloaded files. In an actual use case it would be better to store the checksums externally from this repository, allowing this one to act purely as an executor, and the other repository acting as a &amp;ldquo;record&amp;rdquo; of the known-good commit SHAs (as well as &lt;code&gt;.sign/.ack&lt;/code&gt; files to chain &amp;ldquo;trust&amp;rdquo;)&lt;/p&gt;</description></item><item><title>github-config-in-code</title><link>https://workbench.jrbeverly.ca/2022/03/jrbeverly-github-config-in-code/</link><pubDate>Wed, 02 Mar 2022 02:14:31 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2022/03/jrbeverly-github-config-in-code/</guid><description>&lt;h1 id="github-configuration-in-code"&gt;GitHub Configuration in Code&lt;/h1&gt;
&lt;p&gt;Fiddling with the configuration options available for GitHub, while encoding the properties in the &lt;code&gt;.github&lt;/code&gt; directory.&lt;/p&gt;
&lt;h2 id="getting-started"&gt;Getting Started&lt;/h2&gt;
&lt;p&gt;This repository&lt;/p&gt;
&lt;p&gt;The concept is to create an almost &amp;ldquo;self-contained&amp;rdquo; repository, that includes within hidden directories like &lt;code&gt;.github/.aws/.azure/.gcp/etc&lt;/code&gt; that represent almost &amp;ldquo;interfaces&amp;rdquo; between the repository and external services that would act on it. This way rather than having the repository rely on assumptions about how it is configured, it is instead providing all the baseline elements for any supporting infrastructure (e.g. operators) to provide these integrations themselves.&lt;/p&gt;</description></item><item><title>github-app-for-code-change</title><link>https://workbench.jrbeverly.ca/2022/02/jrbeverly-github-app-for-code-change/</link><pubDate>Wed, 23 Feb 2022 00:11:59 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2022/02/jrbeverly-github-app-for-code-change/</guid><description>&lt;h1 id="github-app-for-generated-commits"&gt;GitHub App for Generated Commits&lt;/h1&gt;
&lt;p&gt;Running through a bunch of things to be done with this&lt;/p&gt;
&lt;h2 id="notes"&gt;Notes&lt;/h2&gt;
&lt;ul&gt;
&lt;li&gt;Is it possible to push empty commits, which would need to be handled&lt;/li&gt;
&lt;li&gt;Commits should be crafted first, then attempts being made to apply the change&lt;/li&gt;
&lt;li&gt;Would need to have better visibility into the &amp;ldquo;crafted&amp;rdquo; files that will be committed&lt;/li&gt;
&lt;li&gt;Does this really require a GitHub Application? Feels like this could be decoupled&lt;/li&gt;
&lt;li&gt;Need to ensure that requests with the API go through the proper retry processes&lt;/li&gt;
&lt;li&gt;Need to ensure that the configuration is split from auth, so its easier to rotate the auth without fiddling with the config&lt;/li&gt;
&lt;li&gt;Should the app really be responsible for the work-component of crafting the change?&lt;/li&gt;
&lt;li&gt;Should all changes be made as a pull request + request to merge from the GitHub App? This would avoid conflicts as much, and let GitHub be responsible for changes?&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;Does this kind of thing really need a GitHub Application? Feels like this is something that can be split away from GitHub as a kind of entity that is responsible for the following actions:&lt;/p&gt;</description></item><item><title>gpg-artifact-sign-exp</title><link>https://workbench.jrbeverly.ca/2022/01/jrbeverly-gpg-artifact-sign-exp/</link><pubDate>Thu, 27 Jan 2022 02:07:13 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2022/01/jrbeverly-gpg-artifact-sign-exp/</guid><description>&lt;h1 id="gpg-artifact-sign-experiment"&gt;GPG Artifact Sign Experiment&lt;/h1&gt;
&lt;p&gt;Minor experiment with a shell script for signing artifacts that would be generated from a build process.&lt;/p&gt;
&lt;h2 id="notes"&gt;Notes&lt;/h2&gt;
&lt;ul&gt;
&lt;li&gt;Build tooling can support multiple checksum algorithms (sha256/sha1/md5/sha512/etc)&lt;/li&gt;
&lt;li&gt;Docker Container Trust (DCT) didn&amp;rsquo;t fit with the usecase/portability desired&lt;/li&gt;
&lt;li&gt;GPG is the standard way for doing this (can this be packaged into something more portable?)&lt;/li&gt;
&lt;li&gt;Design should aim to be agnostic of GitHub Releases or any other platform&lt;/li&gt;
&lt;li&gt;Build tooling likely doesn&amp;rsquo;t need to understand the concept of &amp;ldquo;signing&amp;rdquo; (or should it?)&lt;/li&gt;
&lt;li&gt;If build tools understand signing, does that mean there need to be &amp;lsquo;Developer Keys&amp;rsquo;?
&lt;ul&gt;
&lt;li&gt;Is this really just as just a matter of familiarity?&lt;/li&gt;
&lt;/ul&gt;
&lt;/li&gt;
&lt;li&gt;The CI/Build process is responsible for signing files to assert that &amp;ldquo;it&amp;rdquo; was responsible for the build (e.g. not just dev artifacts published to S3)&lt;/li&gt;
&lt;/ul&gt;</description></item><item><title>bevy-rustlang-example-window</title><link>https://workbench.jrbeverly.ca/2022/01/jrbeverly-bevy-rustlang-example-window/</link><pubDate>Thu, 27 Jan 2022 02:02:45 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2022/01/jrbeverly-bevy-rustlang-example-window/</guid><description>&lt;h1 id="rusy-bevy-baseline"&gt;Rusy Bevy Baseline&lt;/h1&gt;
&lt;p&gt;Fiddling with one of the Bevy examples for provisioning a window with Bevy.&lt;/p&gt;
&lt;h2 id="notes"&gt;Notes&lt;/h2&gt;
&lt;ul&gt;
&lt;li&gt;Initialize setup required installation of libraries like: libasound2-dev libwebkit2gtk-4.0 libudev-dev mingw-w64&lt;/li&gt;
&lt;li&gt;Cross-compilation works, but associated GitHub Issues seemed conflicting&lt;/li&gt;
&lt;li&gt;Earlier version of bevy had issue with missing audio driver (devcontainer) failing the build&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;Don&amp;rsquo;t think will continue with this for now, maybe investigate later.&lt;/p&gt;</description></item><item><title>exp-webassembly-golang-bazel</title><link>https://workbench.jrbeverly.ca/2022/01/jrbeverly-exp-webassembly-golang-bazel/</link><pubDate>Thu, 27 Jan 2022 00:52:56 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2022/01/jrbeverly-exp-webassembly-golang-bazel/</guid><description>&lt;h1 id="experiment---webassembly-golang--bazel"&gt;Experiment - WebAssembly Golang + Bazel&lt;/h1&gt;
&lt;p&gt;Experimenting with some issues encountering with WebAssembly, Golang &amp;amp; Bazel&lt;/p&gt;
&lt;h1 id="notes"&gt;Notes&lt;/h1&gt;
&lt;ul&gt;
&lt;li&gt;Confirmed issue with syscall/js in the basecase with using &lt;code&gt;goos&lt;/code&gt; and &lt;code&gt;goarch&lt;/code&gt; (toolchains passed as orgs better option?)&lt;/li&gt;
&lt;li&gt;Using a genrule sufficient to workaround the case&lt;/li&gt;
&lt;li&gt;Base case with a simple calculator, using just base HTML&lt;/li&gt;
&lt;li&gt;js.Value conversions, framework wrapper to exist to handle the interop?&lt;/li&gt;
&lt;li&gt;Directory layout of &lt;code&gt;cmd/&lt;/code&gt; and &lt;code&gt;app&lt;/code&gt; feels a bit off, but does help keep the bits separate&lt;/li&gt;
&lt;/ul&gt;</description></item><item><title>packer-overwrite-motd</title><link>https://workbench.jrbeverly.ca/2022/01/jrbeverly-packer-overwrite-motd/</link><pubDate>Thu, 27 Jan 2022 00:27:16 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2022/01/jrbeverly-packer-overwrite-motd/</guid><description>&lt;h1 id="packer-overwrite-motd"&gt;Packer Overwrite MOTD&lt;/h1&gt;
&lt;p&gt;Overwriting the MOTD of pre-baked AMIs using Packer&lt;/p&gt;
&lt;h2 id="notes"&gt;Notes&lt;/h2&gt;
&lt;ul&gt;
&lt;li&gt;Message files are located in &lt;code&gt;/etc/update-motd.d/&lt;/code&gt;&lt;/li&gt;
&lt;li&gt;Existing ones can be purged and replaced with a fixed one&lt;/li&gt;
&lt;li&gt;Likely want to keep the status components (source from existing, overwrite)&lt;/li&gt;
&lt;li&gt;Scripts need to be executable, and include shebang&lt;/li&gt;
&lt;li&gt;Current packer requires AWS for EC2 create/snapshot, can we avoid?&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;This works well for setting up a baseline for the AMIs. Is there a way we can perform this Packer construction without needing to be connected to AWS? As at the moment this more resembles &amp;ldquo;Assembly&amp;rdquo; than &amp;ldquo;Build&amp;rdquo;. Having a daemon (virtualbox/hyper-v) is less optimal, but if it can be solely run on any machine with the installed tools, then that would be preferable.&lt;/p&gt;</description></item><item><title>cobra-cmd-with-docs</title><link>https://workbench.jrbeverly.ca/2022/01/jrbeverly-cobra-cmd-with-docs/</link><pubDate>Wed, 26 Jan 2022 04:11:54 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2022/01/jrbeverly-cobra-cmd-with-docs/</guid><description>&lt;h1 id="cobracmd-with-genmarkdowntree"&gt;CobraCMD with GenMarkdownTree&lt;/h1&gt;
&lt;p&gt;Experiment with the GenMarkdownTree method available with cobrago.&lt;/p&gt;
&lt;h2 id="actions"&gt;Actions&lt;/h2&gt;
&lt;p&gt;The command line utility can be executed by running:&lt;/p&gt;
&lt;div class="highlight"&gt;&lt;pre tabindex="0" class="chroma"&gt;&lt;code class="language-bash" data-lang="bash"&gt;&lt;span class="line"&gt;&lt;span class="cl"&gt;bazel run //cmd/cobradocs version
&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;p&gt;The markdown tree for the docs can be generated by running:&lt;/p&gt;</description></item><item><title>xterm-for-cmd-as-site</title><link>https://workbench.jrbeverly.ca/2022/01/jrbeverly-xterm-for-cmd-as-site/</link><pubDate>Wed, 26 Jan 2022 04:07:04 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2022/01/jrbeverly-xterm-for-cmd-as-site/</guid><description>&lt;h1 id="xterm-for-terminal-as-browser"&gt;XTerm for Terminal as Browser&lt;/h1&gt;
&lt;p&gt;Experimenting with the idea of a minimum environment for running terminal applications in browser. In essence, allowing a user to navigate to &lt;code&gt;example.com/terminal&lt;/code&gt; to view a terminal version of the sites API. With the appropriate token &amp;amp; other bits provided from the browser session tokens.&lt;/p&gt;</description></item><item><title>aws-assumerole-with-cert</title><link>https://workbench.jrbeverly.ca/2022/01/jrbeverly-aws-assumerole-with-cert/</link><pubDate>Wed, 26 Jan 2022 03:27:23 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2022/01/jrbeverly-aws-assumerole-with-cert/</guid><description>&lt;h1 id="aws-assumerole-with-certificate-for-ci"&gt;AWS AssumeRole with Certificate for CI&lt;/h1&gt;
&lt;p&gt;Exploring the concept of using AWS IoT Certificates for authenticating with AWS.&lt;/p&gt;
&lt;p&gt;This came up while working with minio, which supports authentication with certificates:&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;MinIO provides a custom STS API that allows authentication with client X.509 / TLS certificates.&lt;/p&gt;</description></item><item><title>cloudfront-cognito-private-auth</title><link>https://workbench.jrbeverly.ca/2022/01/jrbeverly-cloudfront-cognito-private-auth/</link><pubDate>Wed, 26 Jan 2022 02:50:02 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2022/01/jrbeverly-cloudfront-cognito-private-auth/</guid><description>&lt;h1 id="awss3--aws-cognito"&gt;AWSS3 &amp;amp; AWS Cognito&lt;/h1&gt;
&lt;p&gt;Fiddling with AWS S3 Websites leveraging AWS Cognito for authentication&lt;/p&gt;
&lt;p&gt;Terraform is based on the tutorial &lt;a
 href="https://transcend.io/blog/restrict-access-to-internal-websites-with-beyondcorp/" target="_blank" rel="noreferrer"&gt;https://transcend.io/blog/restrict-access-to-internal-websites-with-beyondcorp/&lt;/a&gt;
 and the public repository: &lt;a
 href="https://github.com/transcend-io/beyondcorp-cloudfront" target="_blank" rel="noreferrer"&gt;https://github.com/transcend-io/beyondcorp-cloudfront&lt;/a&gt;
&lt;/p&gt;
&lt;h2 id="notes"&gt;Notes&lt;/h2&gt;
&lt;ul&gt;
&lt;li&gt;This approach isn&amp;rsquo;t really something I think is great&lt;/li&gt;
&lt;li&gt;The lack of ease configuration for Lambdas, and the need to either embed configuration in the lambda zip, or through AWS SSM is not ideal&lt;/li&gt;
&lt;li&gt;Either a single monolith terraform module, or split between multiple. Adds a lot of overhead which is less than ideal&lt;/li&gt;
&lt;li&gt;AWS S3 just doesn&amp;rsquo;t feel like a good source for storing the S3 artifacts - requires bucket policy + &amp;ldquo;public&amp;rdquo; - Don&amp;rsquo;t like&lt;/li&gt;
&lt;li&gt;Seems more preferable to have something like K8s + Nginx pod - Management of secrets/dns/etc can be externalized then&lt;/li&gt;
&lt;li&gt;Docker images gives the opportunity to sign with something like cosign, ability to &amp;ldquo;extend&amp;rdquo; with URL rewrites/etc through nginx itself&lt;/li&gt;
&lt;li&gt;Authentication can be fronted as part of existing K8s services used by backends&lt;/li&gt;
&lt;li&gt;Entire system can be validated with a local installation of K8s&lt;/li&gt;
&lt;li&gt;Alternative caching layers seem more ideal (e.g. Cloudflare pages / etc), thing that can go infront of the primary service&lt;/li&gt;
&lt;li&gt;Could a k8s-ingress served entity just synchronize with other CDNs?&lt;/li&gt;
&lt;li&gt;Cloudfront &amp;ldquo;deploying&amp;rdquo; wait times are kind of in the way for rapid changes (exists in k8s with pods, but cloudfront just &lt;em&gt;feels&lt;/em&gt; slower?)&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;Overall not really liking this approach, as it doesn&amp;rsquo;t simplify the system as much as I was hoping it would.&lt;/p&gt;</description></item><item><title>rules_docker</title><link>https://workbench.jrbeverly.ca/2022/01/jrbeverly-rules_docker/</link><pubDate>Wed, 12 Jan 2022 01:24:06 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2022/01/jrbeverly-rules_docker/</guid><description>&lt;h1 id="bazel-container-image-rules"&gt;Bazel Container Image Rules&lt;/h1&gt;
&lt;table&gt;
	&lt;thead&gt;
			&lt;tr&gt;
					&lt;th style="text-align: center"&gt;Bazel CI&lt;/th&gt;
			&lt;/tr&gt;
	&lt;/thead&gt;
	&lt;tbody&gt;
			&lt;tr&gt;
					&lt;td style="text-align: center"&gt;&lt;a
 href="https://buildkite.com/bazel/docker-rules-docker-postsubmit" target="_blank" rel="noreferrer"&gt;&lt;figure class="content-image"&gt;
 &lt;img
 src="https://badge.buildkite.com/693d7892250cfd44beea3cd95573388200935906a28cd3146d.svg?branch=master"
 alt="Build status"
 loading="lazy"/&gt;&lt;/figure&gt;
&lt;/a&gt;
&lt;/td&gt;
			&lt;/tr&gt;
	&lt;/tbody&gt;
&lt;/table&gt;
&lt;p&gt;Generated API documentation is in the docs folder, or you can browse it online at
&lt;a
 href="https://docs.aspect.dev/rules_docker" target="_blank" rel="noreferrer"&gt;https://docs.aspect.dev/rules_docker&lt;/a&gt;
&lt;/p&gt;
&lt;h2 id="basic-rules"&gt;Basic Rules&lt;/h2&gt;
&lt;ul&gt;
&lt;li&gt;&lt;a
 href="https://workbench.jrbeverly.ca/docs/container.md#container_image"&gt;container_image&lt;/a&gt;
 (&lt;a
 href="#container_image"&gt;example&lt;/a&gt;
)&lt;/li&gt;
&lt;li&gt;&lt;a
 href="https://workbench.jrbeverly.ca/docs/container.md#container_bundle"&gt;container_bundle&lt;/a&gt;
 (&lt;a
 href="#container_bundle"&gt;example&lt;/a&gt;
)&lt;/li&gt;
&lt;li&gt;&lt;a
 href="https://workbench.jrbeverly.ca/docs/container.md#container_import"&gt;container_import&lt;/a&gt;
&lt;/li&gt;
&lt;li&gt;&lt;a
 href="https://workbench.jrbeverly.ca/docs/container.md#container_load"&gt;container_load&lt;/a&gt;
&lt;/li&gt;
&lt;li&gt;&lt;a
 href="https://workbench.jrbeverly.ca/docs/container.md#container_pull"&gt;container_pull&lt;/a&gt;
 (&lt;a
 href="#container_pull"&gt;example&lt;/a&gt;
)&lt;/li&gt;
&lt;li&gt;&lt;a
 href="https://workbench.jrbeverly.ca/docs/container.md#container_push"&gt;container_push&lt;/a&gt;
 (&lt;a
 href="#container_push"&gt;example&lt;/a&gt;
)&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;These rules used to be &lt;code&gt;docker_build&lt;/code&gt;, &lt;code&gt;docker_push&lt;/code&gt;, etc. and the aliases for
these (mostly) legacy names still exist largely for backwards-compatibility. We
also have &lt;strong&gt;early-stage&lt;/strong&gt; &lt;code&gt;oci_image&lt;/code&gt;, &lt;code&gt;oci_push&lt;/code&gt;, etc. aliases for folks that
enjoy the consistency of a consistent rule prefix. The only place the
format-specific names currently do any more than alias things is in &lt;code&gt;foo_push&lt;/code&gt;,
where they also specify the appropriate format as which to publish the image.&lt;/p&gt;</description></item><item><title>dapper-with-entity-model</title><link>https://workbench.jrbeverly.ca/2021/10/jrbeverly-dapper-with-entity-model/</link><pubDate>Sat, 23 Oct 2021 14:43:17 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2021/10/jrbeverly-dapper-with-entity-model/</guid><description>&lt;h1 id="entitymodel-dapper-experiment-case"&gt;EntityModel Dapper Experiment Case&lt;/h1&gt;
&lt;p&gt;Exported case of experimenting with using Postgres Functions, Dapper &amp;amp; Entity.Model.&lt;/p&gt;
&lt;h2 id="notes"&gt;Notes&lt;/h2&gt;
&lt;p&gt;Experimenting a bit more with the entity model of splitting out the &amp;ldquo;database&amp;rdquo; components (e.g. &lt;code&gt;ID&lt;/code&gt;) from the model objects, with an aim towards designing a strict interface for working with the database, that could be generated from a baseline specification. This would allow for things like ReadOnly entities, better field filtering &amp;amp; potential for &amp;ldquo;programmatic&amp;rdquo; improvements to how the database handles searches.&lt;/p&gt;</description></item><item><title>cue-for-schema-gen</title><link>https://workbench.jrbeverly.ca/2021/10/jrbeverly-cue-for-schema-gen/</link><pubDate>Sat, 23 Oct 2021 00:46:21 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2021/10/jrbeverly-cue-for-schema-gen/</guid><description>&lt;h1 id="cuelang-with-schemagen"&gt;Cuelang with SchemaGen&lt;/h1&gt;
&lt;p&gt;Experimenting with using Cuelang for the purposes of representing a schema, then generating associated files from the original source of truth&lt;/p&gt;
&lt;h2 id="notes"&gt;Notes&lt;/h2&gt;
&lt;ul&gt;
&lt;li&gt;Schema validation is nice, the base case is straightforward&lt;/li&gt;
&lt;li&gt;Combining data with this allows for connecting enum/datasets&lt;/li&gt;
&lt;li&gt;What about stubbing of datasets (e.g. restrict this to &amp;lsquo;Dataset&amp;rsquo; that isn&amp;rsquo;t locally defined?)&lt;/li&gt;
&lt;li&gt;Text templating isn&amp;rsquo;t really what I want to do with this kind of tool&lt;/li&gt;
&lt;li&gt;Seems like I need to write more &amp;ldquo;representation/composition&amp;rdquo; than I originally hoped&lt;/li&gt;
&lt;li&gt;Doesn&amp;rsquo;t seem to support the kind of &amp;ldquo;intentions&amp;rdquo; workflow I was hoping for&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;This isn&amp;rsquo;t handling the case I&amp;rsquo;m interested in with schema validation &amp;amp; generation. Although it provides a lot of the base essentials out of the box, I&amp;rsquo;m looking more for a cross between schema+terraform. A system that allows the tracking of version drift, and reconcilation as part of its design.&lt;/p&gt;</description></item><item><title>bazel-bash-packaged</title><link>https://workbench.jrbeverly.ca/2021/10/jrbeverly-bazel-bash-packaged/</link><pubDate>Tue, 05 Oct 2021 23:00:41 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2021/10/jrbeverly-bazel-bash-packaged/</guid><description>&lt;h1 id="bazel-bash-packaged"&gt;Bazel Bash Packaged&lt;/h1&gt;
&lt;p&gt;Experimenting with using Bazel &amp;amp; Bats in container images for writing up tests for shell scripts.&lt;/p&gt;
&lt;h2 id="notes"&gt;Notes&lt;/h2&gt;
&lt;p&gt;Sometimes while developing things it can be useful to have a small shell script that performs a simple action or operation, that in the short-term makes sense as a shell script. In this case, it can be useful to add some simple tests to ensure that:&lt;/p&gt;</description></item><item><title>jcompiler</title><link>https://workbench.jrbeverly.ca/2021/10/jrbeverly-jcompiler/</link><pubDate>Mon, 04 Oct 2021 23:31:06 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2021/10/jrbeverly-jcompiler/</guid><description>&lt;h1 id="jcompiler"&gt;JCompiler&lt;/h1&gt;
&lt;h2 id="summary"&gt;Summary&lt;/h2&gt;
&lt;p&gt;A Joos programming language compiler, written in Java.&lt;/p&gt;
&lt;h2 id="getting-started"&gt;Getting Started&lt;/h2&gt;
&lt;p&gt;The project is currently not maintained or kept in runnable order. You may be able to open the project in Eclipse, but at this time the code is only here as readonly.&lt;/p&gt;</description></item><item><title>bazel-toolchain-from-s3</title><link>https://workbench.jrbeverly.ca/2021/09/jrbeverly-bazel-toolchain-from-s3/</link><pubDate>Sun, 26 Sep 2021 23:53:42 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2021/09/jrbeverly-bazel-toolchain-from-s3/</guid><description>&lt;h1 id="bazel-toolchain-from-s3"&gt;bazel-toolchain-from-s3&lt;/h1&gt;
&lt;p&gt;Experimenting with setting up Bazek toolchains, when the tools are mirrored into an AWS S3 bucket.&lt;/p&gt;
&lt;p&gt;This builds off previous work done in jrbeverly/bazel-external-toolchain-rule for creating toolchains from files.&lt;/p&gt;
&lt;h2 id="notes"&gt;Notes&lt;/h2&gt;
&lt;ul&gt;
&lt;li&gt;Implementation of &lt;code&gt;s3_archive&lt;/code&gt; uses that same model as &lt;code&gt;http_archive&lt;/code&gt;&lt;/li&gt;
&lt;li&gt;The &lt;code&gt;repository_rule&lt;/code&gt; does not use &lt;code&gt;toolchains&lt;/code&gt; like rules, meaning bootstrap rules must be downloaded by &lt;code&gt;repository_ctx&lt;/code&gt;&lt;/li&gt;
&lt;li&gt;Repository rules can convert labels to paths using the &lt;code&gt;repository_ctx.path&lt;/code&gt; method&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;To get a fully managed system that doesn&amp;rsquo;t require tools to be installed on the local system, would likely require a bootstrap rule using a tool that is publicly available. This way it could be downloaded using the &lt;code&gt;download_and_extract&lt;/code&gt; rule of Bazel, then combined with the other rules for perform the act of downloading binaries. The process as follows:&lt;/p&gt;</description></item><item><title>bazel-external-toolchain-rules</title><link>https://workbench.jrbeverly.ca/2021/09/jrbeverly-bazel-external-toolchain-rules/</link><pubDate>Sun, 26 Sep 2021 22:20:07 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2021/09/jrbeverly-bazel-external-toolchain-rules/</guid><description>&lt;h1 id="bazel-external-toolchain-rules"&gt;bazel-external-toolchain-rules&lt;/h1&gt;
&lt;p&gt;Experimenting with setting up Bazel toolchains using an externally managed &lt;code&gt;.toolchain&lt;/code&gt; file, that is responsible for defining properties such as:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;System compatibility&lt;/li&gt;
&lt;li&gt;Integrity Checks&lt;/li&gt;
&lt;li&gt;Tool retrieval locations&lt;/li&gt;
&lt;/ul&gt;
&lt;h2 id="notes"&gt;Notes&lt;/h2&gt;
&lt;p&gt;This idea came out of the idea of having Bazel rules that were not aware of how toolchains were defined (or what systems they are compatible with), and instead being entirely based on the lock file (&lt;code&gt;.toolchain&lt;/code&gt;) available in the caller environment. This means that the bazel rules can in essence just be extensions of the command line specification.&lt;/p&gt;</description></item><item><title>bazel-jsonnett-templates</title><link>https://workbench.jrbeverly.ca/2021/09/jrbeverly-bazel-jsonnett-templates/</link><pubDate>Sun, 12 Sep 2021 17:15:18 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2021/09/jrbeverly-bazel-jsonnett-templates/</guid><description>&lt;h1 id="bazel--jsonnet-templates"&gt;Bazel &amp;amp; Jsonnet Templates&lt;/h1&gt;
&lt;p&gt;Generating files from base configuration files using Jsonnet.&lt;/p&gt;
&lt;h2 id="notes"&gt;Notes&lt;/h2&gt;
&lt;p&gt;Exploring the idea of leveraging jsonnet with Bazel to create a series of templates sourced from configuration files. The basic principle of this is how to built in-repository the idea of &lt;code&gt;∀ ∈ Configuration Files { template([inputs]) =&amp;gt; rendered }&lt;/code&gt;.&lt;/p&gt;</description></item><item><title>internal-reserved-license-repo</title><link>https://workbench.jrbeverly.ca/2021/09/jrbeverly-internal-reserved-license-repo/</link><pubDate>Sat, 11 Sep 2021 19:18:11 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2021/09/jrbeverly-internal-reserved-license-repo/</guid><description>&lt;h1 id="internal-reserved-license-repo"&gt;internal-reserved-license-repo&lt;/h1&gt;
&lt;p&gt;Experimenting with laying out the licensing stamp for a closed/internal source repository&lt;/p&gt;
&lt;h2 id="notes"&gt;Notes&lt;/h2&gt;
&lt;p&gt;Experimenting with the idea of what license annotations would look like on an internal repository that is not intended for public distribution. This can seem odd, as the source code files of the project should not be distributed, so the only individuals viewing the license should be those with pre-approved access (i.e. contributors/employees).&lt;/p&gt;</description></item><item><title>github-actions-dbx-upload</title><link>https://workbench.jrbeverly.ca/2021/08/jrbeverly-github-actions-dbx-upload/</link><pubDate>Sat, 28 Aug 2021 22:26:52 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2021/08/jrbeverly-github-actions-dbx-upload/</guid><description>&lt;h1 id="github-actions-dbx-upload"&gt;github-actions-dbx-upload&lt;/h1&gt;
&lt;p&gt;Publishing to Dropbox programmatically from GitHub Actions with the intentions to mirror the model of AWS S3 publishing.&lt;/p&gt;
&lt;h2 id="notes"&gt;Notes&lt;/h2&gt;
&lt;p&gt;Exploring how one might leverage Dropbox as an artifact storage source, with an authentication model that is similar to AWS. Setting up the initial Dropbox Application to get the tokens for publishing was a bit more involved than useful, and I suspect the process of rotating these tokens might be a pain too.&lt;/p&gt;</description></item><item><title>terraform-aws-codepipeline-terraform-runner</title><link>https://workbench.jrbeverly.ca/2021/08/jrbeverly-terraform-aws-codepipeline-terraform-runner/</link><pubDate>Sat, 28 Aug 2021 14:39:46 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2021/08/jrbeverly-terraform-aws-codepipeline-terraform-runner/</guid><description>&lt;h1 id="terraform-aws-codepipline-terraform-executor"&gt;Terraform AWS CodePipline Terraform Executor&lt;/h1&gt;
&lt;p&gt;Terraform executor leveraging the CodePipeline functionality in AWS, for a fully serverless model of executing terraform in AWS.&lt;/p&gt;
&lt;h2 id="getting-started"&gt;Getting Started&lt;/h2&gt;
&lt;p&gt;The primary environment is configured in &lt;code&gt;env/&lt;/code&gt;, with a single main file. This provisions the CodePipeline, CodeBuild components, as well as some stub S3 buckets that represent both incoming sources, artifacts. The artifacts bucket is treated as a stand-in for the Terraform state environment variable, but the pipeline itself does not attempt to configure the backend for S3.&lt;/p&gt;</description></item><item><title>golang-analyzer-inline-bazel</title><link>https://workbench.jrbeverly.ca/2021/08/jrbeverly-golang-analyzer-inline-bazel/</link><pubDate>Wed, 18 Aug 2021 01:16:50 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2021/08/jrbeverly-golang-analyzer-inline-bazel/</guid><description>&lt;h1 id="bazel-golang-inline-analyzer"&gt;Bazel Golang Inline Analyzer&lt;/h1&gt;
&lt;p&gt;Experimenting with having analyzers locally defined to a repository, rather than externally defined.&lt;/p&gt;
&lt;h2 id="notes"&gt;Notes&lt;/h2&gt;
&lt;ul&gt;
&lt;li&gt;Requires using &lt;code&gt;go_tool_library&lt;/code&gt; instead of &lt;code&gt;go_library&lt;/code&gt; due to a dependency change issue (must also use &lt;code&gt;go_tool_library&lt;/code&gt; of deps)&lt;/li&gt;
&lt;li&gt;Baked natively into &lt;code&gt;nogo&lt;/code&gt;, so it can be pretty straightforward to test&lt;/li&gt;
&lt;li&gt;Names of types aren&amp;rsquo;t as simple as &lt;code&gt;package.Type&lt;/code&gt;, but instead include other components (using &lt;code&gt;HasSuffix&lt;/code&gt;) (What options are there?)&lt;/li&gt;
&lt;li&gt;Change in &amp;lsquo;internal/cobrago/storage.go@ListFilesInStorage&amp;rsquo; can be removed as a test case for the errors&lt;/li&gt;
&lt;li&gt;The &lt;code&gt;tools/&lt;/code&gt; directory probably isn&amp;rsquo;t the best path. Want something that we can spin-out/externalize as these evolve with the code&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;Overall this is a pretty good way to start prototyping mechanisms for code analysis that is right next to the code, which can then later be spun out into their own generic analyzers. As it runs automatically with &lt;code&gt;nogo&lt;/code&gt;, there is a natural way of enabling an analyzer in a tiered manner (warning =&amp;gt; error).&lt;/p&gt;</description></item><item><title>github-app-golang</title><link>https://workbench.jrbeverly.ca/2021/07/jrbeverly-github-app-golang/</link><pubDate>Fri, 16 Jul 2021 16:57:05 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2021/07/jrbeverly-github-app-golang/</guid><description>&lt;h1 id="github-app-in-golang-prototyping"&gt;GitHub App in Golang Prototyping&lt;/h1&gt;
&lt;p&gt;GitHub App written in Golang with the AWS &amp;amp; GitHub integrations split away, to try and encode the core &amp;lsquo;concepts&amp;rsquo; solely into the lib/ component&lt;/p&gt;
&lt;h2 id="notes"&gt;Notes&lt;/h2&gt;
&lt;ul&gt;
&lt;li&gt;Development (&amp;amp; Testing) should support a non-smee way of development&lt;/li&gt;
&lt;li&gt;How would integration/infrastructure/e2e tests work with this kind of system?&lt;/li&gt;
&lt;li&gt;Would it make more sense to have an OpenAPI system, with the GitHub integration performing the interface?&lt;/li&gt;
&lt;li&gt;Is this similar to Hubot, in that having an interface layer/service makes more sense, as it avoids the requirement for direct interface? (This can be within the system itself)&lt;/li&gt;
&lt;/ul&gt;</description></item><item><title>k3s-at-home-poc</title><link>https://workbench.jrbeverly.ca/2021/07/jrbeverly-k3s-at-home-poc/</link><pubDate>Mon, 12 Jul 2021 20:40:29 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2021/07/jrbeverly-k3s-at-home-poc/</guid><description>&lt;h1 id="k3s-in-homelab-proof-of-concept"&gt;K3s In HomeLab Proof of Concept&lt;/h1&gt;
&lt;p&gt;Determining how viable it would to be switch from using docker-compose to using K3s to run my internal homelab environment.&lt;/p&gt;
&lt;h2 id="getting-started"&gt;Getting Started&lt;/h2&gt;
&lt;p&gt;The installation process assumes that you have a freshly imaged ubuntu machine, connected to the internal network, and with a minimum of password-based SSH access.&lt;/p&gt;</description></item><item><title>gitpod-cobra-golang</title><link>https://workbench.jrbeverly.ca/2021/07/jrbeverly-gitpod-cobra-golang/</link><pubDate>Mon, 12 Jul 2021 19:10:27 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2021/07/jrbeverly-gitpod-cobra-golang/</guid><description>&lt;h1 id="gitpod-golang-cli"&gt;GitPod Golang CLI&lt;/h1&gt;
&lt;p&gt;Leveraging GitPod for prototyping out a golang cli that interfaces with AWS.&lt;/p&gt;
&lt;h2 id="notes"&gt;Notes&lt;/h2&gt;
&lt;ul&gt;
&lt;li&gt;The &lt;code&gt;.gitpod.yml&lt;/code&gt; file must exist in the root directory&lt;/li&gt;
&lt;li&gt;Dockerfile(s) for the environment can be specified in its own directory (&lt;code&gt;.gitpod&lt;/code&gt;)&lt;/li&gt;
&lt;li&gt;Commands can be run on start-up, ensuring that the build is working as expected&lt;/li&gt;
&lt;li&gt;GitHub Permissions required to make changes to GitHub Actions workflows&lt;/li&gt;
&lt;li&gt;GitHub Permissions required for a series of commit/pull request based actions&lt;/li&gt;
&lt;li&gt;Workspaces can be provisioned/stopped/cleaned up on-demand&lt;/li&gt;
&lt;li&gt;Docker works on the provisioned nodes&lt;/li&gt;
&lt;li&gt;Extensions &amp;amp; Other components are defined by the &lt;code&gt;.gitpod.yml&lt;/code&gt; file&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;In comparison, the code-server approach is to bake all the dependencies into the same image that is running code-server itself. This means that extensions/settings/etc can be baked onto the image that are common across projects. If working in Docker, it requires a bit more process to work with other docker processes (running on same &lt;code&gt;docker network&lt;/code&gt;, matching file system paths, etc).&lt;/p&gt;</description></item><item><title>rust-lang-checks</title><link>https://workbench.jrbeverly.ca/2021/07/jrbeverly-rust-lang-checks/</link><pubDate>Mon, 12 Jul 2021 15:05:14 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2021/07/jrbeverly-rust-lang-checks/</guid><description>&lt;h1 id="rust-language-checks"&gt;Rust Language Checks&lt;/h1&gt;
&lt;p&gt;Experimenting with aspects of Rustlang for working with database, and immutable data structures.&lt;/p&gt;
&lt;h2 id="notes"&gt;Notes&lt;/h2&gt;
&lt;ul&gt;
&lt;li&gt;How might the Entity.Model apply to this? Where we split the &lt;code&gt;id&lt;/code&gt; from the data struct?&lt;/li&gt;
&lt;li&gt;Immutable hashmap appears to need additional crates (cursory look)&lt;/li&gt;
&lt;li&gt;The &lt;code&gt;/src&lt;/code&gt; &amp;amp; &lt;code&gt;/lib&lt;/code&gt; standard directories is a nice component&lt;/li&gt;
&lt;li&gt;Using &lt;code&gt;.env&lt;/code&gt; to reference the database URL&lt;/li&gt;
&lt;li&gt;Requires some additional components for PSQL &amp;amp; Diesel&lt;/li&gt;
&lt;/ul&gt;</description></item><item><title>packer-bake-with-aws-native</title><link>https://workbench.jrbeverly.ca/2021/05/jrbeverly-packer-bake-with-aws-native/</link><pubDate>Sat, 01 May 2021 01:10:12 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2021/05/jrbeverly-packer-bake-with-aws-native/</guid><description>&lt;h1 id="packer-bakery-with-aws-native"&gt;Packer Bakery with AWS Native&lt;/h1&gt;
&lt;p&gt;Creating pre-baked AMIs using Packer within AWS Native resources (Codepipeline / CodeBuild).&lt;/p&gt;
&lt;h2 id="notes"&gt;Notes&lt;/h2&gt;
&lt;ul&gt;
&lt;li&gt;Tuning minimum permissions can be a bit difficult with the CodePipeline/CodeBuild error messages&lt;/li&gt;
&lt;li&gt;Artifacts bucket should store only temporary/cache files, and should be destroyable&lt;/li&gt;
&lt;li&gt;Logs from CodePipeline &amp;amp; CodeBuild can be restricted to a specific log group&lt;/li&gt;
&lt;li&gt;Unique &amp;lsquo;key&amp;rsquo; identifier allow single-use of module within a common key-scope&lt;/li&gt;
&lt;li&gt;Events on-complete require additional resources/overhead&lt;/li&gt;
&lt;li&gt;Image is amazon pre-built, installing Packer on-the-fly&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;Although nice to leverage IAM solely for this, the benefits don&amp;rsquo;t really outway the issues with leveraging CodePipeline for this kind of build. Splitting this CI/artifact process is less than ideal, but granting credentials to external providers that can spin up any EC2 &amp;amp; run arbitrary scripts has its concern points.&lt;/p&gt;</description></item><item><title>bazel-and-aws-cdk</title><link>https://workbench.jrbeverly.ca/2021/04/jrbeverly-bazel-and-aws-cdk/</link><pubDate>Tue, 27 Apr 2021 23:00:39 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2021/04/jrbeverly-bazel-and-aws-cdk/</guid><description>&lt;h1 id="bazel-and-aws-cdk"&gt;bazel-and-aws-cdk&lt;/h1&gt;
&lt;p&gt;Prototyping ideas with using Bazel and AWS Cloud Development Kit to create cloudformation templates&lt;/p&gt;</description></item><item><title>repository-template-file-invoke-prototype</title><link>https://workbench.jrbeverly.ca/2021/03/jrbeverly-repository-template-file-invoke-prototype/</link><pubDate>Thu, 25 Mar 2021 21:47:15 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2021/03/jrbeverly-repository-template-file-invoke-prototype/</guid><description>&lt;h1 id="repository-templating--file-automation"&gt;Repository Templating &amp;amp; File Automation&lt;/h1&gt;
&lt;p&gt;Experimenting with a model of building a lightweight cron+bash system for performing templating&amp;amp;file modification to multiple repositories.&lt;/p&gt;
&lt;h2 id="idea"&gt;Idea&lt;/h2&gt;
&lt;p&gt;The basics of this repository was the idea of leveraging the GitHub CLI (&lt;code&gt;gh&lt;/code&gt;) to automate the creation of pull requests that were intended to facilitate common chore work in repositories. This would reduce the need to handle things like setting up license files, formatting, metadata, GitHub Actions, etc.&lt;/p&gt;</description></item><item><title>dotfiles</title><link>https://workbench.jrbeverly.ca/2021/03/jrbeverly-dotfiles/</link><pubDate>Sun, 21 Mar 2021 02:26:13 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2021/03/jrbeverly-dotfiles/</guid><description>&lt;h1 id="dotfiles"&gt;dotfiles&lt;/h1&gt;
&lt;p&gt;A set of vim, zsh, git, and configuration files.&lt;/p&gt;</description></item><item><title>ml-learning-lab</title><link>https://workbench.jrbeverly.ca/2021/03/jrbeverly-ml-learning-lab/</link><pubDate>Tue, 16 Mar 2021 02:03:08 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2021/03/jrbeverly-ml-learning-lab/</guid><description>&lt;h1 id="machine-learning-lab"&gt;Machine Learning Lab&lt;/h1&gt;
&lt;p&gt;A repository for aggregating my machine learning exercises, practices and learning labs. The projects included in this repository are based on the coursework for Udacity&amp;rsquo;s Deep Learning Nanodegree Foundations. These are primarily from working on the Machine Learning Nanodegree offered by Udacity.&lt;/p&gt;</description></item><item><title>codespace</title><link>https://workbench.jrbeverly.ca/2021/03/jrbeverly-codespace/</link><pubDate>Mon, 08 Mar 2021 01:03:04 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2021/03/jrbeverly-codespace/</guid><description>&lt;h1 id="codespace"&gt;Codespace&lt;/h1&gt;
&lt;p&gt;Prebuilt, development environment in the browser – powered by VS Code.&lt;/p&gt;
&lt;p&gt;This image acts as a catch-all image for doing full-stack development in a polyglot type environment. The running container makes use of the host docker service to allow for docker builds.&lt;/p&gt;</description></item><item><title>home</title><link>https://workbench.jrbeverly.ca/2020/11/jrbeverly-home/</link><pubDate>Sat, 28 Nov 2020 02:46:39 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2020/11/jrbeverly-home/</guid><description>&lt;h1 id="homelab---internal-tooling"&gt;HomeLab - Internal Tooling&lt;/h1&gt;
&lt;p&gt;Ansible playbooks for configuring services running within my internal home cloud.&lt;/p&gt;
&lt;h2 id="getting-started"&gt;Getting Started&lt;/h2&gt;
&lt;h3 id="devcontainers"&gt;DevContainers&lt;/h3&gt;
&lt;p&gt;The DevContainer environment can be started by opening the repository in VSCode and installing the &amp;lsquo;Remote - Containers&amp;rsquo; extension. When started, the prompt will build and image and configure the container.&lt;/p&gt;</description></item><item><title>aws-lightsail-codespaces</title><link>https://workbench.jrbeverly.ca/2020/08/jrbeverly-aws-lightsail-codespaces/</link><pubDate>Thu, 20 Aug 2020 22:21:48 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2020/08/jrbeverly-aws-lightsail-codespaces/</guid><description>&lt;h1 id="running-code-server-on-aws-lightsail"&gt;Running code-server on AWS Lightsail&lt;/h1&gt;
&lt;h2 id="summary"&gt;Summary&lt;/h2&gt;
&lt;p&gt;Run VS Code on an AWS Lightsail instance with auto-generated password and static IP. Early experiments with cloud-driven development environments configured on-demand using terraform.&lt;/p&gt;
&lt;p&gt;Initial exploratory work for seeing what changes exist in the workflows, and any issues that may arise as a result of working in Lightsail.&lt;/p&gt;</description></item><item><title>aws-lambda-simple-service</title><link>https://workbench.jrbeverly.ca/2020/08/jrbeverly-aws-lambda-simple-service/</link><pubDate>Wed, 19 Aug 2020 23:16:36 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2020/08/jrbeverly-aws-lambda-simple-service/</guid><description>&lt;h1 id="express-in-deployments"&gt;Express in Deployments&lt;/h1&gt;
&lt;p&gt;A simple Express application built with the intent to test an Express server running in different environments (local, docker, lambda).&lt;/p&gt;
&lt;h2 id="usage"&gt;Usage&lt;/h2&gt;
&lt;p&gt;The available make commands can be listed with &lt;code&gt;make help&lt;/code&gt;:&lt;/p&gt;</description></item><item><title>jrbeverly.web</title><link>https://workbench.jrbeverly.ca/2020/06/jrbeverly-jrbeverly.web/</link><pubDate>Sat, 27 Jun 2020 21:01:56 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2020/06/jrbeverly-jrbeverly.web/</guid><description>&lt;h1 id="jrbeverly"&gt;jrbeverly&lt;/h1&gt;
&lt;p&gt;Represents the infrastructure resources of &amp;lsquo;jrbeverly&amp;rsquo;, keeping track of infrastructure components, assets and other resources that are needed for components.&lt;/p&gt;
&lt;h2 id="directory-mappings"&gt;Directory Mappings&lt;/h2&gt;
&lt;p&gt;The directory layout is modelled after the Linux directories (/var, /etc/, /root, /srv, /opt, etc). This is intended to handle cases as they are adopted into the standards.&lt;/p&gt;</description></item><item><title>boston-housing</title><link>https://workbench.jrbeverly.ca/2020/02/jrbeverly-boston-housing/</link><pubDate>Mon, 24 Feb 2020 17:50:55 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2020/02/jrbeverly-boston-housing/</guid><description>&lt;h1 id="predicting-boston-housing-prices"&gt;Predicting Boston Housing Prices&lt;/h1&gt;
&lt;p&gt;Evaluate the performance and predictive power of a model that has been trained and tested on data collected from homes in suburbs of Boston, Massachusetts. A model trained on this data that is seen as a good fit could then be used to make certain predictions about a home — in particular, its monetary value. This model would prove to be invaluable for someone like a real estate agent who could make use of such information on a daily basis.&lt;/p&gt;</description></item><item><title>charityml</title><link>https://workbench.jrbeverly.ca/2020/02/jrbeverly-charityml/</link><pubDate>Mon, 24 Feb 2020 17:50:35 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2020/02/jrbeverly-charityml/</guid><description>&lt;h1 id="finding-donors-for-charityml"&gt;Finding Donors for CharityML&lt;/h1&gt;
&lt;p&gt;Employ several supervised algorithms to accurately model individuals&amp;rsquo; income using data collected from the 1994 U.S. Census. From the best candidate algorithm from preliminary results and further optimize this algorithm to best model the data. Construct a model that accurately predicts whether an individual makes more than $50,000. This sort of task can arise in a non-profit setting, where organizations survive on donations. Understanding an individual&amp;rsquo;s income can help a non-profit better understand how large of a donation to request, or whether or not they should reach out to begin with. While it can be difficult to determine an individual&amp;rsquo;s general income bracket directly from public sources, we can (as we will see) infer this value from other publically available features.&lt;/p&gt;</description></item><item><title>customer-segments</title><link>https://workbench.jrbeverly.ca/2020/02/jrbeverly-customer-segments/</link><pubDate>Mon, 24 Feb 2020 17:48:47 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2020/02/jrbeverly-customer-segments/</guid><description>&lt;h1 id="creating-customer-segments"&gt;Creating Customer Segments&lt;/h1&gt;
&lt;p&gt;Analyze a dataset containing data on various customers&amp;rsquo; annual spending amounts (reported in monetary units) of diverse product categories for internal structure. One goal of this project is to best describe the variation in the different types of customers that a wholesale distributor interacts with. Doing so would equip the distributor with insight into how to best structure their delivery service to meet the needs of each customer.&lt;/p&gt;</description></item><item><title>dog-project</title><link>https://workbench.jrbeverly.ca/2020/01/jrbeverly-dog-project/</link><pubDate>Sat, 11 Jan 2020 18:05:28 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2020/01/jrbeverly-dog-project/</guid><description>&lt;h1 id="classification-of-dogs"&gt;Classification of Dogs&lt;/h1&gt;
&lt;p&gt;My implementation of the Convolutional Neural Networks (CNN) algorithm for identifying a canine’s breed from an image. Additionally, it supply the resembled dog breed if provided an image of a human.&lt;/p&gt;</description></item><item><title>quadcopter</title><link>https://workbench.jrbeverly.ca/2020/01/jrbeverly-quadcopter/</link><pubDate>Fri, 10 Jan 2020 02:31:05 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2020/01/jrbeverly-quadcopter/</guid><description>&lt;h1 id="quadcopter-using-reinforcement-learning"&gt;Quadcopter using Reinforcement Learning&lt;/h1&gt;
&lt;p&gt;My implementation of the DDPG reinforcement learning algorithm to solve the problem of a quadcopter taking flight.&lt;/p&gt;
&lt;p&gt;I have included a reference to the DDPG paper used in the development of the flying agent:&lt;/p&gt;</description></item><item><title>bmx</title><link>https://workbench.jrbeverly.ca/2020/01/jrbeverly-bmx/</link><pubDate>Wed, 08 Jan 2020 18:15:28 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2020/01/jrbeverly-bmx/</guid><description>&lt;h1 id="bmx"&gt;BMX&lt;/h1&gt;
&lt;p&gt;BMX grants you API access to your AWS accounts, based on Okta credentials that you already own.&lt;br&gt;
It uses your Okta identity to create short-term AWS STS tokens, as an alternative to long-term IAM access keys.
BMX manages your STS tokens with the following commands:&lt;/p&gt;</description></item><item><title>git-timeline</title><link>https://workbench.jrbeverly.ca/2020/01/jrbeverly-git-timeline/</link><pubDate>Sat, 04 Jan 2020 01:26:48 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2020/01/jrbeverly-git-timeline/</guid><description>&lt;h1 id="git-timeline"&gt;Git Timeline&lt;/h1&gt;
&lt;p&gt;Allows bulk modification of the commit dates of a repository, changing the history of a repository.&lt;/p&gt;
&lt;h2 id="usage"&gt;Usage&lt;/h2&gt;
&lt;div class="highlight"&gt;&lt;pre tabindex="0" class="chroma"&gt;&lt;code class="language-bash" data-lang="bash"&gt;&lt;span class="line"&gt;&lt;span class="cl"&gt;&lt;span class="c1"&gt;# Creates the demo repository&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span class="line"&gt;&lt;span class="cl"&gt;./git-timeline.bash clone
&lt;/span&gt;&lt;/span&gt;&lt;span class="line"&gt;&lt;span class="cl"&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span class="line"&gt;&lt;span class="cl"&gt;&lt;span class="c1"&gt;# Copies the demo repository to the working environment&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span class="line"&gt;&lt;span class="cl"&gt;./git-timeline.bash working
&lt;/span&gt;&lt;/span&gt;&lt;span class="line"&gt;&lt;span class="cl"&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span class="line"&gt;&lt;span class="cl"&gt;&lt;span class="c1"&gt;# Exports the history of the git repository to files&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span class="line"&gt;&lt;span class="cl"&gt;./git-timeline.bash &lt;span class="nb"&gt;history&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;p&gt;You can then edit the dates of the three files emitted:&lt;/p&gt;</description></item><item><title>aws-lambda-remote-session</title><link>https://workbench.jrbeverly.ca/2020/01/jrbeverly-aws-lambda-remote-session/</link><pubDate>Fri, 03 Jan 2020 22:26:00 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2020/01/jrbeverly-aws-lambda-remote-session/</guid><description>&lt;h1 id="aws-lambda-powershell-example"&gt;AWS Lambda PowerShell Example&lt;/h1&gt;
&lt;p&gt;A simple Lambda function written in PowerShell to validate if &lt;code&gt;New-PSSession&lt;/code&gt; can be leveraged from an AWS Lambda.&lt;/p&gt;
&lt;p&gt;The objective of this repository was to determine if it was possible to use &lt;code&gt;New-PSSession&lt;/code&gt; from an AWS Lambda. This would allow for modification of services like Office365 using remote sessions from AWS without requiring an ECS/EC2 container. Without a custom lambda runtime (or some way of enabling WSMan), it would be difficult to do this with a vanilla lambda execution environment. The error encountered during runtime is included below:&lt;/p&gt;</description></item><item><title>aws-chat-app</title><link>https://workbench.jrbeverly.ca/2019/12/jrbeverly-aws-chat-app/</link><pubDate>Mon, 30 Dec 2019 23:57:22 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2019/12/jrbeverly-aws-chat-app/</guid><description>&lt;h1 id="aws-chat-app"&gt;AWS Chat App&lt;/h1&gt;
&lt;p&gt;SAM Application for a simple chat application based on API Gateways new WebSocket API feature. This was originally developed as an experiment to see how viable running a chat-bot in a fully serverless environment, as opposed to just running on a container in ECS.&lt;/p&gt;</description></item><item><title>hubot-in-aws</title><link>https://workbench.jrbeverly.ca/2019/12/jrbeverly-hubot-in-aws/</link><pubDate>Sat, 28 Dec 2019 15:56:31 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2019/12/jrbeverly-hubot-in-aws/</guid><description>&lt;h1 id="hubot-in-aws-ecs"&gt;Hubot in AWS ECS&lt;/h1&gt;
&lt;p&gt;Hubot deployment in AWS using AWS ECS Fargate. This was prototyped out while I was evaluating ChatOps strategies that could be used to wrap existing web interfaces or require minimal overhead.&lt;/p&gt;</description></item><item><title>pwsh-from-github</title><link>https://workbench.jrbeverly.ca/2019/11/jrbeverly-pwsh-from-github/</link><pubDate>Sun, 17 Nov 2019 15:13:06 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2019/11/jrbeverly-pwsh-from-github/</guid><description>&lt;h1 id="powershell-library-on-github"&gt;Powershell Library on GitHub&lt;/h1&gt;
&lt;h2 id="summary"&gt;Summary&lt;/h2&gt;
&lt;p&gt;A powershell library that is installed from GitHub, rather than from Powershellgallery.&lt;/p&gt;
&lt;h2 id="usage"&gt;Usage&lt;/h2&gt;
&lt;p&gt;Downloading from GitHub:&lt;/p&gt;
&lt;div class="highlight"&gt;&lt;pre tabindex="0" class="chroma"&gt;&lt;code class="language-powershell" data-lang="powershell"&gt;&lt;span class="line"&gt;&lt;span class="cl"&gt;&lt;span class="c"&gt;# Enable installing from github&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span class="line"&gt;&lt;span class="cl"&gt;&lt;span class="nb"&gt;Install-Module&lt;/span&gt; &lt;span class="n"&gt;-Name&lt;/span&gt; &lt;span class="n"&gt;InstallModuleFromGitHub&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span class="line"&gt;&lt;span class="cl"&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span class="line"&gt;&lt;span class="cl"&gt;&lt;span class="c"&gt;# Install the module&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span class="line"&gt;&lt;span class="cl"&gt;&lt;span class="nb"&gt;Install-ModuleFromGitHub&lt;/span&gt; &lt;span class="n"&gt;-GitHubRepo&lt;/span&gt; &lt;span class="n"&gt;jrbeverly&lt;/span&gt;&lt;span class="p"&gt;/&lt;/span&gt;&lt;span class="nb"&gt;pwsh-from&lt;/span&gt;&lt;span class="n"&gt;-github&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span class="line"&gt;&lt;span class="cl"&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span class="line"&gt;&lt;span class="cl"&gt;&lt;span class="c"&gt;# Perform Actions&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span class="line"&gt;&lt;span class="cl"&gt;&lt;span class="nb"&gt;Write-Hello&lt;/span&gt; &lt;span class="n"&gt;-Name&lt;/span&gt; &lt;span class="s2"&gt;&amp;#34;World&amp;#34;&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span class="line"&gt;&lt;span class="cl"&gt;&lt;span class="nb"&gt;Write-World&lt;/span&gt; &lt;span class="n"&gt;-Message&lt;/span&gt; &lt;span class="s2"&gt;&amp;#34;LFG&amp;#34;&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;h2 id="notes"&gt;Notes&lt;/h2&gt;
&lt;p&gt;Experimenting with using InstallModuleFromGitHub, instead of using Powershell gallery.&lt;/p&gt;</description></item><item><title>proposals-concept</title><link>https://workbench.jrbeverly.ca/2019/10/jrbeverly-proposals-concept/</link><pubDate>Wed, 30 Oct 2019 03:40:50 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2019/10/jrbeverly-proposals-concept/</guid><description>&lt;h1 id="proposals"&gt;Proposals&lt;/h1&gt;
&lt;p&gt;Experimenting with the underlying infrastructure for a GitHub based proposals mechanisms that deploys to a web resource (website/subpage/etc)&lt;/p&gt;
&lt;h2 id="motivations"&gt;Motivations&lt;/h2&gt;
&lt;ul&gt;
&lt;li&gt;Automation to ensure contribution guidelines are both accessible and followed (e.g. first contribution bot, linting)&lt;/li&gt;
&lt;li&gt;Contribution previews, either by links to markdown rendering or branch previews&lt;/li&gt;
&lt;li&gt;Support for supplemental resources (e.g. &lt;code&gt;assets/list-of-items.csv&lt;/code&gt;)&lt;/li&gt;
&lt;li&gt;Methods to organize the proposals better (date? slugs? IDs?)&lt;/li&gt;
&lt;li&gt;Simple layout in code (minimal overhead), with tooling to move assets into the correct locations&lt;/li&gt;
&lt;li&gt;When working with code, the proposals have some organization mechanism&lt;/li&gt;
&lt;li&gt;Minimal barriers when trying to write a proposal&lt;/li&gt;
&lt;/ul&gt;
&lt;h2 id="notes"&gt;Notes&lt;/h2&gt;
&lt;p&gt;Using date-based directory organization helps for filtering based on the latest proposals. If you are looking for the proposals in the most recent year, its fairly easy to complete that query (&lt;code&gt;ls designs/2019/&lt;/code&gt;). I find that this falls apart when navigating the history for proposals related to a project. I could enforce directory naming standards, but I feel that makes the repository difficult to approach. If I want all the proposals related to a certain project, I&amp;rsquo;d need to use tools like &lt;code&gt;jq&lt;/code&gt; or &lt;code&gt;grep&lt;/code&gt;.&lt;/p&gt;</description></item><item><title>exp-circleci-orbs</title><link>https://workbench.jrbeverly.ca/2019/10/jrbeverly-exp-circleci-orbs/</link><pubDate>Wed, 30 Oct 2019 02:21:11 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2019/10/jrbeverly-exp-circleci-orbs/</guid><description>&lt;h1 id="experimenting-with-circleci-orbs"&gt;Experimenting with CircleCI Orbs&lt;/h1&gt;
&lt;p&gt;Experimenting with CircleCI Orbs for reducing code re-use in templates&lt;/p&gt;
&lt;h2 id="usages"&gt;Usages&lt;/h2&gt;
&lt;p&gt;&lt;strong&gt;cp&lt;/strong&gt;
Deploy to S3&lt;/p&gt;
&lt;div class="highlight"&gt;&lt;pre tabindex="0" class="chroma"&gt;&lt;code class="language-yml" data-lang="yml"&gt;&lt;span class="line"&gt;&lt;span class="cl"&gt;&lt;span class="nt"&gt;orbs&lt;/span&gt;&lt;span class="p"&gt;:&lt;/span&gt;&lt;span class="w"&gt;
&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;span class="line"&gt;&lt;span class="cl"&gt;&lt;span class="w"&gt; &lt;/span&gt;&lt;span class="nt"&gt;awscli&lt;/span&gt;&lt;span class="p"&gt;:&lt;/span&gt;&lt;span class="w"&gt; &lt;/span&gt;&lt;span class="l"&gt;jrbeverly/awscli@0.0.5&lt;/span&gt;&lt;span class="w"&gt;
&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;span class="line"&gt;&lt;span class="cl"&gt;&lt;span class="nt"&gt;version&lt;/span&gt;&lt;span class="p"&gt;:&lt;/span&gt;&lt;span class="w"&gt; &lt;/span&gt;&lt;span class="m"&gt;2.1&lt;/span&gt;&lt;span class="w"&gt;
&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;span class="line"&gt;&lt;span class="cl"&gt;&lt;span class="nt"&gt;workflows&lt;/span&gt;&lt;span class="p"&gt;:&lt;/span&gt;&lt;span class="w"&gt;
&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;span class="line"&gt;&lt;span class="cl"&gt;&lt;span class="w"&gt; &lt;/span&gt;&lt;span class="nt"&gt;Deploy to S3&lt;/span&gt;&lt;span class="p"&gt;:&lt;/span&gt;&lt;span class="w"&gt;
&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;span class="line"&gt;&lt;span class="cl"&gt;&lt;span class="w"&gt; &lt;/span&gt;&lt;span class="nt"&gt;jobs&lt;/span&gt;&lt;span class="p"&gt;:&lt;/span&gt;&lt;span class="w"&gt;
&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;span class="line"&gt;&lt;span class="cl"&gt;&lt;span class="w"&gt; &lt;/span&gt;- &lt;span class="nt"&gt;awscli/aws-copy-to&lt;/span&gt;&lt;span class="p"&gt;:&lt;/span&gt;&lt;span class="w"&gt;
&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;span class="line"&gt;&lt;span class="cl"&gt;&lt;span class="w"&gt; &lt;/span&gt;&lt;span class="nt"&gt;bucket&lt;/span&gt;&lt;span class="p"&gt;:&lt;/span&gt;&lt;span class="w"&gt; &lt;/span&gt;&lt;span class="l"&gt;hello-bucket&lt;/span&gt;&lt;span class="w"&gt;
&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;span class="line"&gt;&lt;span class="cl"&gt;&lt;span class="w"&gt; &lt;/span&gt;&lt;span class="nt"&gt;namespace&lt;/span&gt;&lt;span class="p"&gt;:&lt;/span&gt;&lt;span class="w"&gt; &lt;/span&gt;&lt;span class="l"&gt;some/terraform&lt;/span&gt;&lt;span class="w"&gt;
&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;span class="line"&gt;&lt;span class="cl"&gt;&lt;span class="w"&gt; &lt;/span&gt;&lt;span class="nt"&gt;source&lt;/span&gt;&lt;span class="p"&gt;:&lt;/span&gt;&lt;span class="w"&gt; &lt;/span&gt;&lt;span class="l"&gt;some/path&lt;/span&gt;&lt;span class="w"&gt;
&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;p&gt;&lt;strong&gt;sync&lt;/strong&gt;
Deploy to S3&lt;/p&gt;</description></item><item><title>bazel-csharp-testcases</title><link>https://workbench.jrbeverly.ca/2019/10/jrbeverly-bazel-csharp-testcases/</link><pubDate>Sat, 26 Oct 2019 21:27:51 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2019/10/jrbeverly-bazel-csharp-testcases/</guid><description>&lt;h1 id="bazel-csharp-rules-examples"&gt;Bazel CSharp Rules Examples&lt;/h1&gt;
&lt;h2 id="overview"&gt;Overview&lt;/h2&gt;
&lt;p&gt;This repository provides a set of usages for the bazel csharp rules. The idea behind these examples is to cover edge cases that are encountered during development, and provide a comprehensive test (&amp;amp; prototype) suite.&lt;/p&gt;</description></item><item><title>viewdocs-autodoc</title><link>https://workbench.jrbeverly.ca/2019/10/jrbeverly-viewdocs-autodoc/</link><pubDate>Sat, 05 Oct 2019 20:47:31 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2019/10/jrbeverly-viewdocs-autodoc/</guid><description>&lt;h1 id="viewdocs-autodoc"&gt;Viewdocs Autodoc&lt;/h1&gt;
&lt;p&gt;This was an early concept I was working with for converting metadata files (json/yml) into standard README markdown files using simple bash and templates. Ultimately I did not go in this direction, as I found that I was not making the best use of the customization yielded from using with bash + templates. A simple templating engine provided all the basics that I was ultimately after.&lt;/p&gt;</description></item><item><title>awesome-terraform-prototype</title><link>https://workbench.jrbeverly.ca/2019/10/jrbeverly-awesome-terraform-prototype/</link><pubDate>Sat, 05 Oct 2019 20:41:57 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2019/10/jrbeverly-awesome-terraform-prototype/</guid><description>&lt;h1 id="awesome-terraform-prototype"&gt;Awesome Terraform Prototype&lt;/h1&gt;
&lt;p&gt;An experiment using &lt;code&gt;mkdocs&lt;/code&gt; and a series of json/yml files to define an awesome list.&lt;/p&gt;
&lt;p&gt;The markdown files are automatically generated from the yml files that define each element of the list (tags/metadata/etc). These files are then piped into &lt;code&gt;mkdocs&lt;/code&gt;, which yields a material theme website for the project.&lt;/p&gt;</description></item><item><title>exp-svg-icon-processing</title><link>https://workbench.jrbeverly.ca/2019/10/jrbeverly-exp-svg-icon-processing/</link><pubDate>Sat, 05 Oct 2019 20:37:56 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2019/10/jrbeverly-exp-svg-icon-processing/</guid><description>&lt;h1 id="svg-icon-processing"&gt;SVG Icon Processing&lt;/h1&gt;
&lt;h2 id="summary"&gt;Summary&lt;/h2&gt;
&lt;p&gt;Experiment with programmatically generating color variants for SVG files using a JSON definition file with the source SVG.&lt;/p&gt;
&lt;h2 id="usage"&gt;Usage&lt;/h2&gt;
&lt;p&gt;The variants of each of the files is defined as a dictionary (&lt;code&gt;string:object&lt;/code&gt;). The key for the dictionary matches the name of the variant. The &lt;code&gt;object&lt;/code&gt; defines a collection of &lt;code&gt;id&lt;/code&gt; and properties. These will be merged into the SVG to generate the variant icon. An example definition file is included below.&lt;/p&gt;</description></item><item><title>bullseye-exp</title><link>https://workbench.jrbeverly.ca/2019/10/jrbeverly-bullseye-exp/</link><pubDate>Sat, 05 Oct 2019 20:35:47 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2019/10/jrbeverly-bullseye-exp/</guid><description>&lt;h1 id="bullseye-experimentation"&gt;BullsEye Experimentation&lt;/h1&gt;
&lt;h2 id="summary"&gt;Summary&lt;/h2&gt;
&lt;p&gt;Experiment with BullsEye for building command-driven tooling (build-systems).&lt;/p&gt;
&lt;h2 id="usage"&gt;Usage&lt;/h2&gt;
&lt;p&gt;Experimenting with using BullsEye in a dotnet project. BullsEye doesn&amp;rsquo;t handle parsing of command line arguments, instead recommends using a tool for parsing them.&lt;/p&gt;</description></item><item><title>lab-starter</title><link>https://workbench.jrbeverly.ca/2019/09/jrbeverly-lab-starter/</link><pubDate>Sun, 01 Sep 2019 20:31:22 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2019/09/jrbeverly-lab-starter/</guid><description>&lt;h1 id="github-learning-lab---lab-starter"&gt;GitHub Learning Lab - Lab Starter&lt;/h1&gt;
&lt;p&gt;Noticed this when working with GitHub Actions that you can have a automated &amp;rsquo;teacher&amp;rsquo; by using linting + GitHub Bot. Thought this was an interesting idea, and have started this repository to get a better understanding of how this actually works.&lt;/p&gt;</description></item><item><title>hello-github-actions</title><link>https://workbench.jrbeverly.ca/2019/09/jrbeverly-hello-github-actions/</link><pubDate>Sun, 01 Sep 2019 19:56:26 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2019/09/jrbeverly-hello-github-actions/</guid><description>&lt;h2 id="welcome-to-hello-world-with-github-actions"&gt;Welcome to &amp;ldquo;Hello World&amp;rdquo; with GitHub Actions&lt;/h2&gt;
&lt;p&gt;This course will walk you through writing your first action and using it with a workflow file.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Ready to get started? Navigate to the first issue.&lt;/strong&gt;&lt;/p&gt;</description></item><item><title>dotnet-native-corert</title><link>https://workbench.jrbeverly.ca/2019/02/jrbeverly-dotnet-native-corert/</link><pubDate>Sun, 03 Feb 2019 03:52:04 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2019/02/jrbeverly-dotnet-native-corert/</guid><description>&lt;h1 id="net-core-native-compilation-experiments"&gt;.NET Core Native Compilation Experiments&lt;/h1&gt;
&lt;p&gt;A simple CI/CD pipeline making use of CoreRT to build linux and windows copies of a &amp;ldquo;Hello World&amp;rdquo; console application.&lt;/p&gt;
&lt;h2 id="notes"&gt;Notes&lt;/h2&gt;
&lt;ul&gt;
&lt;li&gt;CoreRT currently does not support compilation cross-compilation (as it is not supported yet).&lt;/li&gt;
&lt;li&gt;AOT for a linux binary requires non-dotnet dependencies (that need to be installed to be base image)&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;At present it is likely best to use Windows docker images for building the dotnet native jobs.&lt;/p&gt;</description></item><item><title>make-exp</title><link>https://workbench.jrbeverly.ca/2018/12/jrbeverly-make-exp/</link><pubDate>Wed, 12 Dec 2018 22:46:15 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2018/12/jrbeverly-make-exp/</guid><description>&lt;h1 id="makefile-experiments"&gt;Makefile Experiments&lt;/h1&gt;
&lt;h2 id="summary"&gt;Summary&lt;/h2&gt;
&lt;p&gt;Experimenting with using makefiles as a build harness type structure. The idea is to package &lt;code&gt;makefile&lt;/code&gt; using GitHub, that can then be downloaded when running.&lt;/p&gt;
&lt;h2 id="conceptual-usage"&gt;Conceptual Usage&lt;/h2&gt;
&lt;p&gt;As the structure is simply an experiment, no targets are actually implemented. At the top of the Makefile, you can include the makefile using the following:&lt;/p&gt;</description></item><item><title>infrastructure-labs</title><link>https://workbench.jrbeverly.ca/2018/11/jrbeverly-infrastructure-labs/</link><pubDate>Fri, 02 Nov 2018 23:41:32 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2018/11/jrbeverly-infrastructure-labs/</guid><description>&lt;h1 id="infrastructure"&gt;Infrastructure&lt;/h1&gt;
&lt;h2 id="summary"&gt;Summary&lt;/h2&gt;
&lt;p&gt;The specification of &lt;code&gt;jrbeverlylabs&lt;/code&gt; as a set of terraform modules.&lt;/p&gt;
&lt;h2 id="usage"&gt;Usage&lt;/h2&gt;
&lt;p&gt;To run this you need to execute:&lt;/p&gt;
&lt;div class="highlight"&gt;&lt;pre tabindex="0" class="chroma"&gt;&lt;code class="language-bash" data-lang="bash"&gt;&lt;span class="line"&gt;&lt;span class="cl"&gt;terraform init
&lt;/span&gt;&lt;/span&gt;&lt;span class="line"&gt;&lt;span class="cl"&gt;terraform plan
&lt;/span&gt;&lt;/span&gt;&lt;span class="line"&gt;&lt;span class="cl"&gt;terraform apply
&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;h2 id="notes"&gt;Notes&lt;/h2&gt;
&lt;p&gt;This was a simple experiment making use of the &lt;code&gt;gitlab&lt;/code&gt; provider of terraform. The idea was to see if it would assist in the process of maintaining &lt;code&gt;jrbeverlylabs&lt;/code&gt; between gitlab.com and my internal gitlab instance.&lt;/p&gt;</description></item><item><title>xunit-metadata</title><link>https://workbench.jrbeverly.ca/2018/11/jrbeverly-xunit-metadata/</link><pubDate>Fri, 02 Nov 2018 00:52:39 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2018/11/jrbeverly-xunit-metadata/</guid><description>&lt;h1 id="xunitmetadata"&gt;XUnit.Metadata&lt;/h1&gt;
&lt;h2 id="summary"&gt;Summary&lt;/h2&gt;
&lt;p&gt;Strongly-typed attributes for the management and organization of tests. As opposed to using strings throughout the code, &lt;code&gt;[Trait(&amp;quot;Category&amp;quot;, &amp;quot;Unit&amp;quot;)]&lt;/code&gt;, you can use strongly-typed attributes for organizing tests.&lt;/p&gt;
&lt;h2 id="getting-started"&gt;Getting Started&lt;/h2&gt;
&lt;p&gt;With xUnit v2 you can markup tests with traits, particullary of interest is the category key. Using traits you can sort tests or control execution of tests from the command line. You can install in your project using the Nuget Manager Console:&lt;/p&gt;</description></item><item><title>wifi-web</title><link>https://workbench.jrbeverly.ca/2018/11/jrbeverly-wifi-web/</link><pubDate>Fri, 02 Nov 2018 00:52:35 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2018/11/jrbeverly-wifi-web/</guid><description>&lt;h1 id="wifi-web"&gt;Wifi Web&lt;/h1&gt;
&lt;h2 id="summary"&gt;Summary&lt;/h2&gt;
&lt;p&gt;Wifi Web provides an autorun USB for connecting to wireless access points for devices that do not have access to a camera. It opens an HTML page that provides easy access to the Wifi connection details.&lt;/p&gt;</description></item><item><title>stack-opengl</title><link>https://workbench.jrbeverly.ca/2018/11/jrbeverly-stack-opengl/</link><pubDate>Fri, 02 Nov 2018 00:52:30 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2018/11/jrbeverly-stack-opengl/</guid><description>&lt;h1 id="stack-opengl"&gt;stack-opengl&lt;/h1&gt;
&lt;h2 id="summary"&gt;Summary&lt;/h2&gt;
&lt;p&gt;stack-opengl is a variant of &lt;code&gt;stack-net&lt;/code&gt; written in OpenGL. It uses extremely simple shaders and OpenGL programming to create a block stacking application.&lt;/p&gt;
&lt;h2 id="getting-started"&gt;Getting Started&lt;/h2&gt;
&lt;p&gt;The project uses &lt;strong&gt;premake4&lt;/strong&gt; as the cross-platform build system. You will need to build the external dependencies of the project, by running a root level build. You can then build the project itself. You can do so as such:&lt;/p&gt;</description></item><item><title>stack-net</title><link>https://workbench.jrbeverly.ca/2018/11/jrbeverly-stack-net/</link><pubDate>Fri, 02 Nov 2018 00:52:29 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2018/11/jrbeverly-stack-net/</guid><description>&lt;h1 id="stack-net"&gt;Stack-NET&lt;/h1&gt;
&lt;h2 id="summary"&gt;Summary&lt;/h2&gt;
&lt;p&gt;A block blueprinter, built using a visual graph style approach to graphics.&lt;/p&gt;
&lt;h2 id="getting-started"&gt;Getting Started&lt;/h2&gt;
&lt;p&gt;The project is based on the old approach to C# projects. The project should be opened in Visual Studio, built, then run.&lt;/p&gt;</description></item><item><title>raytracer</title><link>https://workbench.jrbeverly.ca/2018/11/jrbeverly-raytracer/</link><pubDate>Fri, 02 Nov 2018 00:52:27 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2018/11/jrbeverly-raytracer/</guid><description>&lt;h1 id="raytracer"&gt;RayTracer&lt;/h1&gt;
&lt;h2 id="summary"&gt;Summary&lt;/h2&gt;
&lt;p&gt;A Raytracer that receives a scene defined in lua, and produces an image output.&lt;/p&gt;
&lt;h2 id="getting-started"&gt;Getting Started&lt;/h2&gt;
&lt;p&gt;Compilation follows the standard process defined by the UWaterloo CS488 sample projects.&lt;/p&gt;
&lt;p&gt;We use &lt;strong&gt;premake4&lt;/strong&gt; as our cross-platform build system. First you will need to build all
the static libraries that the projects depend on. To build the libraries, open up a
terminal, and &lt;strong&gt;cd&lt;/strong&gt; to the top level of the CS488 project directory and then run the
following:&lt;/p&gt;</description></item><item><title>profile</title><link>https://workbench.jrbeverly.ca/2018/11/jrbeverly-profile/</link><pubDate>Fri, 02 Nov 2018 00:52:26 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2018/11/jrbeverly-profile/</guid><description>&lt;h1 id="jrbeverlyprofile"&gt;jrbeverly.profile&lt;/h1&gt;
&lt;h2 id="summary"&gt;Summary&lt;/h2&gt;
&lt;p&gt;This is a one page user profile for Jonathan Beverly (jrbeverly - i.e. me), linking to multiple online identities, relevant external sites, and popular social networking websites. Not all of them are included, but most of the relevant ones are.&lt;/p&gt;</description></item><item><title>exp-portfolio</title><link>https://workbench.jrbeverly.ca/2018/11/jrbeverly-exp-portfolio/</link><pubDate>Fri, 02 Nov 2018 00:52:25 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2018/11/jrbeverly-exp-portfolio/</guid><description>&lt;h1 id="jrbeverly-portfolio"&gt;jrbeverly portfolio&lt;/h1&gt;
&lt;h2 id="summary"&gt;Summary&lt;/h2&gt;
&lt;p&gt;Collections data from a specified list of gitlab projects, then converts them into static HTML briefs.&lt;/p&gt;
&lt;h2 id="getting-started"&gt;Getting Started&lt;/h2&gt;
&lt;p&gt;The project is designed to &lt;code&gt;git clone&lt;/code&gt; a series of repository, then collect information from each of them. This includes the project icon, name, license, path, etc.&lt;/p&gt;</description></item><item><title>office-depot</title><link>https://workbench.jrbeverly.ca/2018/11/jrbeverly-office-depot/</link><pubDate>Fri, 02 Nov 2018 00:52:22 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2018/11/jrbeverly-office-depot/</guid><description>&lt;h1 id="office-depot"&gt;office-depot&lt;/h1&gt;
&lt;h2 id="summary"&gt;Summary&lt;/h2&gt;
&lt;p&gt;&lt;code&gt;office-depot&lt;/code&gt; is a container based software development stack.&lt;/p&gt;
&lt;h2 id="getting-started"&gt;Getting Started&lt;/h2&gt;
&lt;p&gt;Getting started is as simple as using &lt;code&gt;docker-compose&lt;/code&gt;. You can do so as such:&lt;/p&gt;
&lt;div class="highlight"&gt;&lt;pre tabindex="0" class="chroma"&gt;&lt;code class="language-bash" data-lang="bash"&gt;&lt;span class="line"&gt;&lt;span class="cl"&gt;docker-compose up --env-file&lt;span class="o"&gt;=&lt;/span&gt;office-depot.env -d
&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;h2 id="updating-and-upgrading"&gt;Updating and Upgrading&lt;/h2&gt;
&lt;p&gt;If you wish to upgrade the container stack, you need to run the following commands:&lt;/p&gt;</description></item><item><title>mirroring</title><link>https://workbench.jrbeverly.ca/2018/11/jrbeverly-mirroring/</link><pubDate>Fri, 02 Nov 2018 00:52:21 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2018/11/jrbeverly-mirroring/</guid><description>&lt;h1 id="mirroring"&gt;Mirroring&lt;/h1&gt;
&lt;h2 id="summary"&gt;Summary&lt;/h2&gt;
&lt;p&gt;A lightweight bash script that allows easy mirroring of projects to external git hosts.&lt;/p&gt;
&lt;h2 id="getting-started"&gt;Getting started&lt;/h2&gt;
&lt;p&gt;Simply fork this repository, as it has all the scripts necessary for performing mirrors. You can then add your repositories into the &lt;code&gt;assets/&lt;/code&gt; directory. You will want to store them as such:&lt;/p&gt;</description></item><item><title>localization-net</title><link>https://workbench.jrbeverly.ca/2018/11/jrbeverly-localization-net/</link><pubDate>Fri, 02 Nov 2018 00:52:18 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2018/11/jrbeverly-localization-net/</guid><description>&lt;h1 id="localizationnet-concept"&gt;Localization.NET Concept&lt;/h1&gt;
&lt;h2 id="summary"&gt;Summary&lt;/h2&gt;
&lt;p&gt;A simple experiment prototyping a concept for strongly typed language terms.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Note: The generated component is not built with this. This is a usage prototype only (no generator is included).&lt;/strong&gt;&lt;/p&gt;</description></item><item><title>issues-style</title><link>https://workbench.jrbeverly.ca/2018/11/jrbeverly-issues-style/</link><pubDate>Fri, 02 Nov 2018 00:52:13 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2018/11/jrbeverly-issues-style/</guid><description>&lt;h1 id="issuesstyle"&gt;Issues.Style&lt;/h1&gt;
&lt;h2 id="summary"&gt;Summary&lt;/h2&gt;
&lt;p&gt;A style guide for issue management, release versioning, Git Flow and repository documentation.&lt;/p&gt;
&lt;h2 id="description"&gt;Description&lt;/h2&gt;
&lt;p&gt;In order to speed up the initialization process of a new gitlab project, Issues.Style provides a set of common labels and issues that might be used when setting up a new project. The project provides methods for quickly setting up the project, specifically providing the following:&lt;/p&gt;</description></item><item><title>project-icons</title><link>https://workbench.jrbeverly.ca/2018/11/jrbeverly-project-icons/</link><pubDate>Fri, 02 Nov 2018 00:52:12 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2018/11/jrbeverly-project-icons/</guid><description>&lt;h1 id="jrbeverlyicons"&gt;jrbeverly.icons&lt;/h1&gt;
&lt;h2 id="summary"&gt;Summary&lt;/h2&gt;
&lt;p&gt;A collection of scalable vector graphics (SVG) that define project and group icons.&lt;/p&gt;
&lt;h2 id="build"&gt;Build&lt;/h2&gt;
&lt;p&gt;You can build the icons using the tool &lt;code&gt;rsvg-convert&lt;/code&gt;. To build with &lt;code&gt;rsvg-convert&lt;/code&gt;, you can do the following:&lt;/p&gt;</description></item><item><title>gitlab-ci-yml</title><link>https://workbench.jrbeverly.ca/2018/11/jrbeverly-gitlab-ci-yml/</link><pubDate>Fri, 02 Nov 2018 00:52:10 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2018/11/jrbeverly-gitlab-ci-yml/</guid><description>&lt;h1 id="gitlab-ciyml"&gt;gitlab-ci.yml&lt;/h1&gt;
&lt;p&gt;A collection of GitLab CI configuration files that are used by my projects. Stored here as the process of docker projects are polished and standardized.&lt;/p&gt;
&lt;h2 id="getting-started"&gt;Getting Started&lt;/h2&gt;
&lt;p&gt;Each of the dockerfiles is presented with a simple &lt;code&gt;.gitlab-ci.yml&lt;/code&gt; file that uses one of my docker images. The resources referenced by the definition are not included in this project. You can start by copying the &lt;code&gt;.gitlab-cy.yml&lt;/code&gt;, then replacing the relevant bits.&lt;/p&gt;</description></item><item><title>entity-net</title><link>https://workbench.jrbeverly.ca/2018/11/jrbeverly-entity-net/</link><pubDate>Fri, 02 Nov 2018 00:52:07 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2018/11/jrbeverly-entity-net/</guid><description>&lt;h1 id="entitynet-concept"&gt;Entity.NET Concept&lt;/h1&gt;
&lt;h2 id="summary"&gt;Summary&lt;/h2&gt;
&lt;p&gt;A simple experiment prototyping a concept for strongly typed ORMs.&lt;/p&gt;
&lt;h2 id="getting-started"&gt;Getting Started&lt;/h2&gt;
&lt;p&gt;The idea that Entity.NET is attempting to conceptualize is one where strongly-typed objects are used with an ORM system. The primary objective is to use strongly typed identifiers (&lt;code&gt;Keys.Customer&lt;/code&gt;) that restricts the usages of an applications ORM. The concept is from the following scenario:&lt;/p&gt;</description></item><item><title>distributedrpc</title><link>https://workbench.jrbeverly.ca/2018/11/jrbeverly-distributedrpc/</link><pubDate>Fri, 02 Nov 2018 00:41:09 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2018/11/jrbeverly-distributedrpc/</guid><description>&lt;h1 id="distributedrpc"&gt;DistributedRPC&lt;/h1&gt;
&lt;h2 id="summary"&gt;Summary&lt;/h2&gt;
&lt;p&gt;A multi-client, multi-server environment that relies on a binder to facilitate an RPC system.&lt;/p&gt;
&lt;h2 id="getting-started"&gt;Getting Started&lt;/h2&gt;
&lt;p&gt;To make (&amp;ldquo;compile and link&amp;rdquo;) all components of the project, you can quickly get started with&lt;/p&gt;</description></item><item><title>contentbundler</title><link>https://workbench.jrbeverly.ca/2018/11/jrbeverly-contentbundler/</link><pubDate>Fri, 02 Nov 2018 00:41:04 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2018/11/jrbeverly-contentbundler/</guid><description>&lt;h1 id="contentbundler"&gt;ContentBundler&lt;/h1&gt;
&lt;h2 id="summary"&gt;Summary&lt;/h2&gt;
&lt;p&gt;A proof of concept for generation of strongly typed paths using the Roslyn Framework.&lt;/p&gt;
&lt;h2 id="getting-started"&gt;Getting Started&lt;/h2&gt;
&lt;p&gt;ContentBundler is provided as an command line application, originally adapted from an XNA Content Compiler. The new version greatly simplifies the code requirements, leveraging Roslyn for the code generation. An example is available from &lt;a
 href="https://github.com/jrbeverly/contentbundler/blob/HEAD/test/assets" target="_blank" rel="noreferrer"&gt;test/assets&lt;/a&gt;
, which will generate the result [PatchQ.cs]&lt;/p&gt;</description></item><item><title>udacicards</title><link>https://workbench.jrbeverly.ca/2018/04/jrbeverly-udacicards/</link><pubDate>Sat, 07 Apr 2018 20:55:53 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2018/04/jrbeverly-udacicards/</guid><description>&lt;h1 id="udacicards"&gt;UdaciCards&lt;/h1&gt;
&lt;h2 id="summary"&gt;Summary&lt;/h2&gt;
&lt;p&gt;For the UdaciCards project, you will build a mobile application (Android or iOS - or both) that allows users to study collections of flashcards. The app will allow users to create different categories of flashcards called &amp;ldquo;decks&amp;rdquo;, add flashcards to those decks, then take quizzes on those decks.&lt;/p&gt;</description></item><item><title>jollybot</title><link>https://workbench.jrbeverly.ca/2018/04/jrbeverly-jollybot/</link><pubDate>Sat, 07 Apr 2018 20:50:44 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2018/04/jrbeverly-jollybot/</guid><description>&lt;h1 id="jollybot"&gt;JollyBot&lt;/h1&gt;
&lt;h2 id="summary"&gt;Summary&lt;/h2&gt;
&lt;p&gt;Prisoners&amp;rsquo; Dilemma A.I. bot performing an &amp;lsquo;Olive Branch&amp;rsquo; strategy focusing on attempting to cooperate whenever possible. The bot attempts to establish cooperation, even in cases where the opposing agent may appear hostile (e.g. always defect).&lt;/p&gt;</description></item><item><title>readable</title><link>https://workbench.jrbeverly.ca/2018/01/jrbeverly-readable/</link><pubDate>Wed, 17 Jan 2018 23:40:48 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2018/01/jrbeverly-readable/</guid><description>&lt;h2 id="readable"&gt;Readable&lt;/h2&gt;
&lt;p&gt;Udacity Nanodegree React Project&lt;/p&gt;
&lt;h2 id="installing-server"&gt;Installing Server&lt;/h2&gt;
&lt;ol&gt;
&lt;li&gt;cd src/api&lt;/li&gt;
&lt;li&gt;npm install&lt;/li&gt;
&lt;li&gt;node start&lt;/li&gt;
&lt;/ol&gt;
&lt;h2 id="installing-client"&gt;Installing Client&lt;/h2&gt;
&lt;ol&gt;
&lt;li&gt;cd src/client&lt;/li&gt;
&lt;li&gt;npm install&lt;/li&gt;
&lt;li&gt;npm start&lt;/li&gt;
&lt;/ol&gt;
&lt;h2 id="api-server"&gt;API Server&lt;/h2&gt;
&lt;p&gt;Information about the API server and how to use it can be found in its &lt;a
 href="https://github.com/jrbeverly/readable/blob/HEAD/src/api-server/README.md" target="_blank" rel="noreferrer"&gt;README file&lt;/a&gt;
.&lt;/p&gt;</description></item><item><title>myreads</title><link>https://workbench.jrbeverly.ca/2017/11/jrbeverly-myreads/</link><pubDate>Sat, 18 Nov 2017 22:49:02 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2017/11/jrbeverly-myreads/</guid><description>&lt;h1 id="myreads-project"&gt;MyReads Project&lt;/h1&gt;
&lt;h2 id="summary"&gt;Summary&lt;/h2&gt;
&lt;p&gt;A digital bookshelf app that allows you to select and categorize books you have read, are currently reading, or want to read.&lt;/p&gt;
&lt;h2 id="description"&gt;Description&lt;/h2&gt;
&lt;p&gt;MyReads is a digital bookshelf app that allows you to select and categorize books you have read, are currently reading, or want to read. It is built as a project for Udacity React Nanodegree.&lt;/p&gt;</description></item><item><title>githooks</title><link>https://workbench.jrbeverly.ca/2017/09/jrbeverly-githooks/</link><pubDate>Sat, 16 Sep 2017 01:04:05 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2017/09/jrbeverly-githooks/</guid><description>&lt;h1 id="githooks"&gt;Githooks&lt;/h1&gt;
&lt;h2 id="summary"&gt;Summary&lt;/h2&gt;
&lt;p&gt;GitHooks provides a multi-hook framework for Git Hooks, along with a collection of scripts for the purposes of encouraging a commit policy, altering the project environment depending on the state of the repository, and implementing continuous integration workflows. The framework allows multi-script execution, you can use GitHooks to automate or optimize virtually any aspect of your development workflow.&lt;/p&gt;</description></item><item><title>homelab</title><link>https://workbench.jrbeverly.ca/2017/05/jrbeverly-homelab/</link><pubDate>Wed, 31 May 2017 22:54:15 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2017/05/jrbeverly-homelab/</guid><description>&lt;h1 id="homelab"&gt;Homelab&lt;/h1&gt;
&lt;h2 id="summary"&gt;Summary&lt;/h2&gt;
&lt;p&gt;A collection of templates and utility scripts used in my homelab. Most of these are just snippets or experiments.&lt;/p&gt;
&lt;h2 id="getting-started"&gt;Getting Started&lt;/h2&gt;
&lt;p&gt;As most of the scripts are self-contained, you can clone the repository:&lt;/p&gt;</description></item><item><title>jotto</title><link>https://workbench.jrbeverly.ca/2017/05/jrbeverly-jotto/</link><pubDate>Wed, 31 May 2017 14:21:28 +0000</pubDate><guid>https://workbench.jrbeverly.ca/2017/05/jrbeverly-jotto/</guid><description>&lt;h1 id="jotto"&gt;Jotto&lt;/h1&gt;
&lt;h2 id="summary"&gt;Summary&lt;/h2&gt;
&lt;p&gt;Jotto is a logic-oriented word game played with two players. Each player picks a secret word of five letters (that is in the dictionary), and the object of the game is to correctly guess the other player&amp;rsquo;s word first. Players take turns guessing and giving the number of Jots, or the number of letters that are in both the guessed word and the secret word.&lt;/p&gt;</description></item></channel></rss>