I've finally updated my blog to use SvelteKit, making it more flexible. I can now create simple markdown files for basic posts or add custom pages for more complex designs. The server automatically builds and deploys a static version to Cloudflare Workers upon GitHub check-ins.

I've added some interactive features like star movement and parallax effects for desktop users. The color scheme is defined using CSS variables and the oklch color space. Icons animate on hover, and summaries are generated using Mistral. Images are automatically resized and cropped, and RSS feeds are available in various formats. The design features a translucent glass and space theme.

This year, I've discovered several tools that have significantly improved my workflow. One of the standouts is Neovim, a highly efficient text editor that has transformed the way I code. Its steep learning curve is worth it, as it offers unparalleled efficiency and support for virtually any programming language. I've even started contributing to plugins on GitHub, which speaks to its robust community and endless customization options.

Another game-changer is Tailscale, a tool that simplifies network management by connecting all my devices into one seamless network. Whether I'm accessing my 3D printer remotely or managing file shares, Tailscale makes it effortless. Its ability to work through NAT gateways and firewalls is a significant advantage, making it an indispensable tool for both personal and professional use.

I've been diving deep into the terminal world lately. I'm even considering moving away from VSCode! It all started with a YouTube video about alternative terminals to iTerm2 on macOS, where I discovered Wezterm. I was instantly hooked, especially because it's multi-platform.

Wezterm has some great features that I'm used to from tmux, so I can drop that. The best part is configuring a "Leader" key, making it easy to split panes or create new tabs. It's been a smooth transition, even on Windows machines using WSL.

I recently delved into the advanced features of GraphQL, specifically focusing on subscriptions. Unlike REST, which is request-based, GraphQL supports subscriptions and push responses, making it more dynamic. To achieve this, GraphQL uses WebSockets, allowing for persistent connections and real-time data updates.

I built a simple chat application to illustrate this. Clients connect to retrieve chat history using basic GraphQL and then receive updates via subscriptions. Initially, the chat history is stored in memory, but I plan to integrate Redis's Pub/Sub mechanism for a more robust solution. This approach can be adapted to other libraries like Kafka or PostgreSQL.

I recently delved into the client-side implementation of GraphQL using React and Apollo. The process involved setting up a basic React application with Apollo as the GraphQL library. Although there was a fair amount of initial boilerplate code, once everything was in place, extending the application became quite straightforward.

I started by creating a new React project using TypeScript and installed the necessary Apollo and GraphQL libraries. The next step was to modify the package.json to include scripts for updating the schema and generating types. This ensured that the client-side code stayed in sync with the server-side schema. The final touch was to create a simple React component that queries the GraphQL server and displays the data.

I recently delved into the practical side of GraphQL by implementing a server using Go. This choice was driven by my recent exploration of the language, and it also serves to demonstrate that GraphQL isn't confined to JavaScript. The coding style for GraphQL libraries is quite consistent across different languages, making it accessible for developers familiar with other languages.

In this post, I walked through the process of setting up a GraphQL server. I started by defining the necessary types and schema, which included user, account, and address types. Each type is composed of basic data types like strings, integers, and floats. The query schema was then defined, including resolvers that handle the actual data fetching and processing. This setup ensures that the server can respond to GraphQL queries effectively, providing a robust and self-documenting API.

I recently explored the origins of GraphQL, a query language for APIs that Facebook developed. It's not an implementation but a specification, with many libraries supporting it. GraphQL emerged as a solution to the limitations of SOAP and REST, offering a more efficient and flexible way to fetch data.

GraphQL provides a clearly defined schema, bringing back type safety lost in the transition from SOAP to REST. It allows clients to request only the data they need, significantly reducing data fetch sizes. Additionally, documentation is defined in code, reducing the risk of mismatches. However, it's not without its challenges, such as potential request bottlenecks and the need for careful resolver management.

I recently explored the key component that sets progressive web apps apart from regular web pages: service workers. These workers act as a proxy between the network and your web page, enabling various functionalities like caching assets for offline access, serving default images, and supporting push notifications.

Service workers operate on a separate thread, which means they don't have access to the DOM or global variables. They also support only asynchronous calls and are initially downloaded after the first page load. Despite these limitations, service workers are a powerful tool for enhancing web app performance and user experience.

I recently shared my experiences from the other side of the desk, focusing on what we look for during interviews. Interviews can indeed be intimidating, but understanding the process can help alleviate some of that stress. I broke down the interview into four key sections to provide a clearer picture of what we're assessing.

Each section of the interview serves a specific purpose, from evaluating technical skills to assessing cultural fit. By understanding these components, candidates can better prepare and present their strengths. This insight not only helps in acing the interview but also in understanding what employers value in potential hires.

In the past decade, the landscape of app development has significantly evolved. Initially, web pages were the primary means of accessing content on mobile devices, but the introduction of the app store changed everything. This shift brought about the need to develop apps for both iOS and Android, leading to the rise of hybrid apps using frameworks like PhoneGap (now Cordova). However, these early hybrid apps often felt unnatural and lacked the performance and feel of native apps.

Today, technologies like React Native have bridged the gap, allowing developers to create apps that feel native while using a unified language. The future seems to be leaning towards Progressive Web Apps (PWAs), which offer the benefits of apps without the need to be on the App Store. PWAs provide offline access and a unified look and feel, making them a strong contender for rapid development and release. As a developer, I see PWAs as the next big stage, offering flexibility and performance for most applications, while native development remains crucial for those needing to maximize device capabilities.