Who am I?
I’m a full-stack developer with a passion for programming. I've been a professional developer for over 8 years, and I'm current working at a leading software services company in Alberta, Canada. Most of my development experience is in building and maintaining enterprise applications across a wide number of different industries. My projects often involve complex ETL orchestration, MSSQL Server, SSIS, dotNET, Entity Framework (EFCore), React, Angular, Django, Ruby on Rails, and more. I'm able to work at a high skill level across many different tech stacks, backend/frontend, DevOps, architecture, etc.
In my free time, I like to write and publish educational content to my technical blog here. I overall just enjoy technical writing and refining my notes and learning materials for quick lookup and on-the-fly development. When I started this site, I was fresh out of school, where I had previously competed, as an undergraduate, in programming competitions in an organization run by ICPC. By the end of my undergraduate I had amassed a huge amount of problem solutions and related code snippets that I felt were just too valuable to me to forget about. I really enjoy topics on data structures, algorithms, and (most importantly) working examples in a "real-world", well-defined scenario. Thus, "Competitive Programming" is now the healthiest section, containing detailed explanations, and code solutions, to a small number of total problems I've solved on these online judge systems (CodeForces, UVa).
What's this blog about?
Like most developers, I accumulate a great deal of information about languages, code snippets, tips & tricks, how-to's, guides, examples, and reference material. I return to my notes all the time; and at this point in my career, organizing materials for quick content retrieval is my main goal. You don't always know what is going to be useful later, and when you come across something interesting and go through the process of getting it to work, it feels wasteful to just throw away that new knowledge.
Modern enterprise apps exist in a vast ecosystem of rapidly-changing technologies. As a rule, I don't care for re-documenting the features of XYZ front-end web framework. For example, you won't see a thorough step-by-step, handheld guide to jQuery 3.4.x. It's just not interesting to me, and MANY other writers and programmers out there are constantly beating this dead horse on their blogs. Instead, I'd be interested in questions like:
How is this static site generated?
Codebarn.ca is a completely static website meant to improve developer/writing experience. I wanted the freedom of hand-writing my own HTML, without the growing pains of such a loose approach as the amount of content grows over time. The basic idea is to create a flexible data model for my blog content, utilizing a backend server running locally, and an HTML template engine with the ability to preprocess simple variable substitutions from the local server.
It's a huge benefit to have a data model, and lets me make big changes to the site across many pages. Essentially, I want to be able to write-up beautiful blog posts made for programmer's eyes. I have, and continue to, collected a huge amount of potentially-useful developer information via disparate notes, markdown files, code-snippet apps, and cloud storage. Some of it is useless, some of it is fantastic but not relevant to my current projects. I want to preserve the best parts of my own library, and put it into a coherent form that can be understood without prior context (and avoid the whole "where the hell is that script?" process); a quick reference guide for myself in the future. And hopefully others can enjoy some of my content as well.
At the moment, I'm experimenting with ways to give the appearance of a full-stack application, and reap some of the benefits of things like TypeScript/React/Etc. without committing to any of these frameworks. Ultimately, the site is static, and the build artifact is merely a directory of HTML files with relative links to navigate between pages. But as the site grows, big changes will become nearly impossible to efficiently do. For example, each post has a header, and over time I might add more metadata to the post object, and I want all the pages to update the same. Essentially, I want a component (e.g. React, Angular); edit once, change everywhere.