Technical Experience

I have many years of industrial TypeScript experience developing strongly typed applications. It is the most robust language in my repertoire.

TypeScript's type system is a fascinating topic. It's a purely functional language with many intuitive features that make it incredibly powerful for describing complicated functions in valuable ways.

I've worked on many small-time Rust projects, like my WPA3-URI, which generates WPA3 Wi-Fi URIs for use in QR codes.

Elm is an excellent language. It has all the features you'd want in an all-in-one framework/ language solution, including server-side rendering. My biggest grumble with Elm is its removal (as a dialect of Haskell) of type classes and higher kinded types. Nonetheless, it's fast and approachable for new users.

I've written some Haskell and contributed to a large distributed backend codebase. A lot of my functional experience was writing fp TypeScript code with fp-ts, which, with a nearly identical API footprint, actually translates quite well to the Haskell world.

PureScript bests Haskell in a few ways, mainly because it's newer and doesn't support language extensions. It produces efficient JavaScript and has all the benefits of a purely functional language, including complete HKT support, type classes, and HKT composition architecture.

Most of my experience with Ruby was in a much older version, fixing bugs and adding minor features to a legacy codebase that fell to the wayside during company churn.

I have published many open-source libraries, and authoring a library in a way everybody can use is tricky. Node 16 makes it difficult for CJS-based and ESM-based packages to work together simultaneously, and publishing for those is challenging. For my projects, I use my own build-tools library, @fp-tx/build-tools, but in other places, I use 'pkgroll,' which does a similar thing but with fewer features.

I've used Yarn the most, and recently, I've started using Yarn Berry. I've had many issues using PNPM workspaces, where pnpm will not install all necessary dependencies. This has led to many hard-to-diagnose bugs, and Yarn Berry has corrected all those issues.

I've used PNPM at Spoonflower and in various open-source projects. I've found it unreliable in a workspace setting, requiring frequent node-module wiping and cache clearing. Yarn Berry significantly improves upon PNPM but requires rigor in defining package JSON dependencies and is slightly more complicated to integrate into a CI context.

I've used React in every developer position I've had. It continues to be the framework of choice for many companies. It has a vast ecosystem, build tool support, is fast, and easily scales. Libraries And Frameworks

NextJS's level of integration is necessary to couple server-side rendering with code-splitting and route-based data transfer. It also encourages good habits like using forms for data submission.

The prototypical Redux architecture was essentially the Elm architecture before its inception. It is an excellent event-driven way to describe state transformations. Perhaps the only better way to describe the state of a complex application would be using a state machine like the one found in XState. I've worked with proprietary tech similar to XState, but one written for an fp-ts/react frontend.

Though I prefer well-structured REST endpoints to GraphQL, GraphQL is feature-rich and composable, and the graph-based resource access is pretty cool.

For SPAs that require the fastest possible performance, Preact speeds up the page render and comes with a slightly smaller bundle size. I use it for my resume website.

Fp-ts is my preferred way of writing TypeScript. What makes fp-ts so great is a rich standard library, a common functional interface between data types, and graceful effect and dependency composition.

Fp-ts has essentially been abandoned in favor of a similar library and ecosystem, "effect-ts." Effect is a direct replacement for Fp-ts, albeit changing the method names and dropping the mathematics-inspired particulars like type-class rules. People tend to prefer Effect, which has many features, some easy to use and others not. Generally, it is an excellent consideration for a TypeScript standard library and effect system.

I was ultimately disappointed when the author of fp-ts abandoned it for effect, so I decided to create my own. Fp-tx is a GitHub organization that seeks to provide equivalent functionality to the many libraries in the fp-ts ecosystem, which I built to be Node 16 ESM/CJS compliant.

I have designed Webpack configs for SPAs and Node SSR servers with client bundles and upgraded ancient Webpack configs to the latest version.

I still choose Vite for SPAs. Whenever I need a fast bundler with hot module reloading (HMR), I opt for Vite. It's a simple configuration, and you have exact access to the HTML contents of the final deliverable.

This site was made with Docusaurus, though highly customized to interoperate with Chakra-ui. I was really surprised by how easy it was, and how well it worked

I created @fp-tx/build-tools to solve the many CJS/ESM issues that arise when developing a node package. Based on a glob-based entry point matcher and using the pacakge.json type field, it will both bundle your library for consumption in strict node ESM/CJS environments and bundle types in ways that TypeScript expects

I used Cloudflared on my home network to provide DNS-over-https and Pihole for ad blocking. However, I switched to ControlD due to reliability issues with Umbrel and Portainer.

I've worked with DNS custom records when setting up GitHub pages and my email providers for apex and subdomains.

ControlD is my current DNS-over-https provider for my home network. It was easy to set up on my Unifi Dream Machine Pro and is fast and reliable. It's also excellent at blocking ads.

I recently rebuilt my home network with a Unifi Dream Machine Pro. I've tailored the firewall settings to my strange VLAN configuration and to adequately support IPV6 with ICMP. It's an excellent replacement for my old router, providing my (supported) devices with Wi-Fi 6E, 2.5G ethernet, and robust security and protection features.

I've worked with Docker and Docker Compose on nearly every project I've touched on in the last few years. It's a straightforward way to create reproducible builds and integrates nicely with Kubernetes.

I have a lot of experience writing GitHub actions, automating a repository's checks, build processes, and publishing.

GitHub actions are the proper way to handle specific workflows. Library/package publishing, for example, benefits tremendously from automation. In particular, it prevents lousy code from landing in the main branch and forces libraries to follow semantic versioning by publishing the changes dictated by conventional commit. And don't get me started on semver.

My experience with Terraform has primarily been in TypeScript but secondarily in YML integrated with a full-stack Kubernetes workflow. So far, I've used it to mainly deploy AWS infrastructure, particularly Kubernetes with Atlantis and Kustomize.

Schemata-ts, a parsing and validation library I built for fp-ts, has deep integration with JSON schema Draft-07, 2019-09, and 2020-12

I continue to prefer compliant REST APIs to other data services like GraphQL. In general, it closely abides by SOLID principles and permits graceful versioning so that clients can rely on a predictable API surface.

I grew up using Macs. My grandpa and dad were avid Mac users, and nothing has changed! I use Windows for gaming and an alternate system with NixOS, but my daily driver is a Mac, both for personal projects and work. I know just about everything there is to know about Macs.

I'm adept with Linux operating systems and bash-style command lines. It's not been my sole focus, but I've worked on and built a handful of Linux systems and use ZSH every day.

I'm experimenting with NixOS as a primary machine to replace a Windows gaming machine. I'm happy with how deterministic NixOS builds are. They make it really easy to install, set things up, and revert. And with Flakes and Home Manager, it might be the best operating system ever conceived.

SOLID principles define ways to organize code, making it highly testable, maintainable, and easy to reason. Additionally, it's useful for many paradigms, though initially, it was chiefly for object-oriented programming and dependency injection in low-level languages.

• Separation of Concerns – A class or service should not involve methods or effects unrelated to its core function.
• Open-Closed Principle – A class or service should be open for extension but closed to modification
• Liskov Substitution Principle – An instance of a class or service should completely satisfy, in itself, a dependency of the class or service it implements.
• Interface Segregation Principle – The dependencies of a class or service should be as small as possible
• Dependency Inversion Principle (Inversion of Control) – Consumers of a class or service can determine functionality by selecting particular providers.

An excellent book by Scott Wlaschin, 'Domain Modeling Made Functional,' illustrates the concept of a complex order-manufacturing system written in a domain/event-driven way. In this case, it's written for functional programming in F#.