The last couple of years have been a magical time for AI fans, with new tools, AI models, services, or apps popping up every other week. As someone who was very skeptical at the start, I thought it would be interesting to reflect on how AI has changed my workflow and review what I’m currently using.

A quick disclaimer: I’m not a fan of the term “AI” since nothing we have right now deserves to be called “artificial intelligence.” These are just machine learning data models. But for the sake of consistency, I will refer to them as “AI” since it is now the accepted way to refer to machine learning.

I have been helping to lead a GraphQL team at a large organization. The goal of my team is to create a scalable GraphQL platform and increase its adoption within this company. When I joined the team, we'd already gone through several iterations and failed to onboard any consumer in the 1 - 2 year period. The approach at the time of my joining was to use schema stitching with an open-source framework called GraphQL Mesh. After experiencing numerous challenges and we are now shifting to Apollo Federation as an alternative, which as the name suggests federates the schema instead of stitching them. In this article, I will share the differences between these two approaches and walk through my experiences with them including why we making the switch, particularly in regards to scalability and stability.

ChatGPT was released back in November 2022, and it caused quite a stir online. Scaremongers have been saying it will change everything and AI is ready to take jobs from us. There are also sceptics which said it won't change anything. I was interested in how good ChatGPT was, so I decided to do an experiment and have been testing it out myself in the past couple of months. I wanted to see if it could help me to learn iOS mobile app development and how it faired compared to widely used methods such as "googling" and following text or video tutorials.

Building a GraphQL API requires a deep understanding of the technology and best practices. It offers developers a high level of control and freedom, which is why it is so easy to get started. However, it is also why people can design themselves into a corner if they are not careful. Security and performance implications are just typical issues of software development. GraphQL also requires that the schema is well-designed and easy to maintain; otherwise, the development team will run into a world of pain. Additionally, the development team must be trained and skilled in using GraphQL, as it requires a different way of thinking about data and APIs. In this article, let's discuss when it is a good choice to adopt GraphQL and who it is for.

I ran into this issue recently where esbuild was complaining about the CPU architecture in VS Code. The project was running SvelteKit (v1) for some context. The error didn't disrupt anything I was doing, but I was sick of seeing the error message everywhere and decided to fix it. I've always run Rosetta v2 on my Apple silicon Macs because of compatibility concerns. Here's my article on Setting up ZSH with VS Code on Apple silicon Mac (M1 chip). But this was the first time Rosetta caused any conflicts in my workflows. I found a fix at the end and decided to share it, given how little people have written about this.

The built-in Date object is notoriously difficult to use. It is why there are several date libraries out there, such as Day.js, luxon, date-fns, etc. Recently, I've implemented a date library that acts as a light abstraction layer, providing syntactic sugar like the date libraries mentioned above. I won't go into detail about why I didn't just use one of those libraries in this article, and I will save that for another time. Instead, I want to discuss my learnings and recommendation after learnings from creating this date library.

I upgraded to MacBook Pro 14" a few months back. I've been using it for personal development and commercial contracts (working inside large teams) with no problem. For anyone who's on the fence about buying a Mac with Apple silicon (AKA M1 chip), I would encourage them to go for it. I want to point out that the lack of issues could be because I'm running all codebases with Resetta 2, an emulator that could translate Intel chip commands so they could run on Apple Silicon. In this article, I'll share my setup in case it helps anyone out there.

SvelteKit doesn't come with unit test tools out of the box, so we'll have to configure our own. Usually, I'd add in Jest because it's always been my favourite testing framework. However, I recently heard good things about Vitest and thought I'd give it a try. For those unfamiliar with Vitest, it is a drop-in replacement for Jest and is much faster. In addition, I've noticed another benefit of how simple it is to configure compared to Jest since it natively supports TypeScript. However, we still need to do a couple of things to get Vitest working properly with SvelteKit. Let's go through what these things are.

Although Svelte/SvelteKit support other CSS preprocessors, nothing comes baked-in so we need to manually install dependencies in order to use them in our project. In this blog post, we'll go over the simplest way to achieve this.

As I've mentioned in a previous blog post Becoming an interview engineer, I have been an interview engineer at Karat for about six months now. As an interviewer, it is my job to observe different candidates attempt the same questions. Over time, I noticed something intriguing - the best performing candidates I interviewed all use the same programming language. To make it clear, Karat allows candidates to pick from 26 programming languages (excluding Markdown) when attempting coding interviews. Out of these languages, candidates tend to choose the same few languages. Out of these languages, there's a clear winner when it comes to the best language to use for coding interviews - Python. Of course, candidates can still perform well using other languages, but I strongly feel the interviewing "game" is rigged against them.