<p>Hello world! This is my first-ever blog post. Cool, right?</p>
<h2>Who's behind the keyboard?</h2>
<p>That would be me, Szymon, a frontend software engineer. Recently, I have joined Microsoft to work on an internal monitoring &#x26; telemetry platform. Sounds familiar? Before that I was developing a large-scale SaaS observability (yep, monitoring) platform at Sumo Logic. It definitely seems like coding interactive dashboards and charts is my thing!</p>
<p>Lately, I've been having many thoughts and no place to share them. That's why I decided to build my personal website.</p>
<p>Interestingly, this isn't its first version. In fact, if you dig into commit history 😁, you will see I had a similar website some time ago. Life got busy, and I moved on, but the source code stayed on GitHub. I thought, why not give it another shot? So, armed with the lessons I've learned over the years, here we are again.</p>
<h2>The old vs the new - Static Side Generation</h2>
<p>I consider Static Site Generation a must for static sites which don't change much over time. It minimizes data transfer between the client and the server. It also paves the way for static hosting - a more cost-effective &#x26; faster way of hosting React apps than using Docker containers.</p>
<p>Old version of my website used <a href="https://www.gatsbyjs.com/">Gatsby</a> for SSG. Now it's all about <a href="https://nextjs.org/">Next.js</a>. Why make the jump?</p>
<p>Well, Next.js is rapidly becoming the go-to React framework. With the release of Next.js 13 and its Server Side Components, it's now the talk of the town in the frontend space. I wanted to dive in, see its benefits first-hand, and perhaps refresh some of the features I might have overlooked.</p>
<p>That said, it's not just about the tech. While I've observed fairly similar build times and other key metrics with both, I must say - and this is purely subjective - the developer experience feels more streamlined on Next.js compared to Gatsby.</p>
<h2>What can you expect?</h2>
<p>I'll mostly post about the technology world. Expect deep dives into frontend topics, handy programming tips &#x26; tricks, and occasional articles on self-development. However, I'm not (currently 😁) aiming to be next <a href="https://blog.pragmaticengineer.com/">The Pragmatic Engineer</a> - my posts will be somewhat shorter!</p>
<p>Every so often, I'll also write about my passions. Right now, that's motorcycles &#x26; cars, sci-fi literature. But hey, these change!</p>
<h3>How often?</h3>
<p>I'm aiming for biweekly posts, but don't be surprised if something pops up sooner (or perhaps a bit later).</p>
<h2>What's next?</h2>
<p>I have plans for a few upcoming posts. I want to create a detailed write-up on coding a blog from scratch (part 0 - preparations, decisions, architecture; part 1 - actual implementation, tips &#x26; tricks; part 2 - transitioning to Server Side Components).</p>
<p>Apart from that, I recently did some job interviews and helped some friends prep &#x26; secure jobs. I have many insights on crafting resumes/CVs and preparing for interviews. I will certainly share these here.</p>
<h2>Other places</h2>
<p>I'll be cross-posting each piece on my <a href="https://dev.to/szymonpulut">dev.to</a> blog. I'll also share updates on my <a href="https://linkedin.com/in/szymonpulut/">LinkedIn</a> with each new post. If you're into the old-school vibe, there's always the <a href="https://szymonpulut.com/feed.xml">RSS feed</a> to keep you in the loop.</p>
<h2>To my Sumo friends</h2>
<p>I want to say a heartfelt thank you to all my colleagues at Sumo Logic. Working in such tech-savvy environment has been an incredible experience and learning opportunity. However, this would've been all nothing if not for all the amazing people at Sumo. Thanks! I'm confident our paths will cross again in future 😉.</p>


Hello World! Welcome to my new site!

<p>Let's kick things off with a quick peek at the web app — it's all about displaying a sleek and clutter-free dashboard, somewhat similar in functionality to <a href="https://www.home-assistant.io/">Home Assistant</a>. I intentionally kept the functionality limited to maintain that clean, minimalist design. IoT Dashboard is deployed on a Raspberry Pi and displayed on a simple tablet mounted in my house.</p>
<p><img src="/images/iotdashboard.webp" alt="Screenshot of IoT Dashboard"></p>
<p>If you'd like to visit the repository, the link is here <a href="https://github.com/szymonpulut/IoTDashboard/">https://github.com/szymonpulut/IoTDashboard/</a>.</p>
<h2>A Bit of Background</h2>
<p>This application has been on quite a journey. I first built it a few years ago using pure JavaScript and direct DOM manipulations. Then, as I was learning React in 2019, I felt it was time for a rewrite. This transition marked a significant milestone for me, as it really showcased the power and simplicity of React.</p>
<p>This current version is the third iteration of the app. My goal this time was to elevate it to a production-grade level. I also wanted to challenge myself by making it full-stack, using Node.JS for the backend and GraphQL for seamless frontend-backend communication.</p>
<h2>Big Picture Overview</h2>
<p>Throughout the development process for both UI and backend applications, I focused on a couple of core principles:</p>
<ol>
<li>
<p><strong>Modularity</strong>: The app needed to be fully modular, making it easier to understand and extend in the future.</p>
</li>
<li>
<p><strong>Streamlined Process</strong>: I automated the CI/CD process, adopting tools like <a href="https://www.conventionalcommits.org/en/v1.0.0/">Conventional Commits</a> with <a href="https://github.com/googleapis/release-please">Release Please</a>, along with <a href="https://prettier.io/">Prettier</a> and <a href="https://eslint.org/">ESLint</a> for code styling and rule enforcement. <a href="https://typicode.github.io/husky/">Husky</a> handles linting on commit. While automated testing wasn't a priority initially, I plan to add some basic coverage down the road.</p>
</li>
<li>
<p><strong>File Naming Conventions</strong>: Both frontend and backend codebases adhere to clear naming conventions, facilitating file location and organization.</p>
</li>
</ol>
<h2>Frontend: The User Interface</h2>
<h3>Overview</h3>
<p>The UI is neatly organized into sections, aligned with CSS grid display areas. Key features include a clock, weather forecast, air quality measurements, temperature sensor data from around the house, control functionality for front gates, and integration with a shared Google Calendar.</p>
<p>For local development, I stick to simple <code>npm</code> commands, while deployment is made easy with <a href="https://www.docker.com/">Docker</a> and <a href="https://docs.docker.com/compose/">Docker Compose</a>.</p>
<h3>Technical Details</h3>
<p>The frontend focuses on simplicity, as most of the heavy lifting is done by the backend. It's built with React and TypeScript. Styled with <a href="https://styled-components.com/">styled-components</a>, and utilizes <a href="https://www.apollographql.com/docs/react/">Apollo Client</a> for GraphQL communications. The frontend build process is powered by lightning-fast <a href="https://vitejs.dev/">Vite</a>.</p>
<h2>Backend: The Real Core</h2>
<p>My expertise lies more in frontend development, so this project has been a valuable learning experience. I learned a lot about backend architecture, coding in Node.JS, and implementing a GraphQL server.</p>
<h3>Apollo Server &#x26; GraphQL</h3>
<p>To maintain modularity, I relied on <a href="https://the-guild.dev/graphql/tools">@graphql-tools</a> and custom code to ensure flexibility in schema and resolver management.</p>
<h3>Modules</h3>
<p>Modules, housed in the <a href="https://github.com/szymonpulut/IoTDashboard/tree/55f15878f21f588b3aceaa883d6a3b697a0a8cd8/server/src/api">/api/ directory</a>, come in two types:</p>
<ol>
<li>
<p><strong>Internal</strong>: These modules interact with internal smart home systems, like <a href="https://github.com/szymonpulut/IoTDashboard/tree/55f15878f21f588b3aceaa883d6a3b697a0a8cd8/server/src/api/gateControl">front gate control</a>, using <a href="https://mqtt.org/">MQTT</a> for communication (MQTT is a message broker similar to RabbitMQ or Kafka, specifically optimized for IoT devices).</p>
</li>
<li>
<p><strong>External</strong>: These modules interface with external APIs, like the <a href="https://github.com/szymonpulut/IoTDashboard/tree/55f15878f21f588b3aceaa883d6a3b697a0a8cd8/server/src/api/weather">weather forecast</a>, primarily fetching data via REST APIs. Responses are parsed with <a href="https://github.com/colinhacks/zod">zod</a> for full type safety.</p>
</li>
</ol>
<p>GraphQL schemas are defined in <code>.schema.graphql</code> files, with exposed actions listed in <code>.resolver.</code> files. Actions themselves are in <code>.dataSources.</code> and <code>.mutations.</code> files (for fetching and mutating data, respectively). Internal modules may also have <code>.handler.</code> files in a <code>/handlers/</code> subdirectory for handling incoming MQTT system broadcasts.</p>
<h3>Custom Utilities</h3>
<ul>
<li>
<p><strong>Fetching</strong>: I've developed a <a href="https://github.com/szymonpulut/IoTDashboard/blob/55f15878f21f588b3aceaa883d6a3b697a0a8cd8/server/src/utils/fetchData.utils.ts">data-fetching function</a> for consistent integration with <code>zod</code> and <a href="https://github.com/szymonpulut/IoTDashboard/blob/main/server/src/utils/cacheManager.utils.ts">simple caching</a>.</p>
</li>
<li>
<p><strong>MQTT</strong>: The MQTT setup, detailed in the <a href="https://github.com/szymonpulut/IoTDashboard/tree/55f15878f21f588b3aceaa883d6a3b697a0a8cd8/server/src/mqtt">/mqtt/ directory</a>, includes pre-defined topics and mappings for subscriptions and mutations. Secrets are managed via <a href="https://github.com/szymonpulut/IoTDashboard/blob/55f15878f21f588b3aceaa883d6a3b697a0a8cd8/server/src/mqtt/mqtt.topics.secret.example.ts">mqtt.topics.secret - example</a>, avoiding hardcoded values.</p>
</li>
</ul>
<h2>Challenges Faced</h2>
<p>The journey wasn't without its hurdles. Here are a couple of interesting challenges I encountered:</p>
<ol>
<li>
<p><strong>Setting up TypeScript in the backend</strong> proved more cumbersome than expected due to Node.JS's limitations in this area. Overcoming issues with <code>tsconfig</code> as well as imports during build &#x26; dev flows was particularly challenging.</p>
</li>
<li>
<p><strong>On the backend’s side, managing multiple GraphQL resolvers and schemas</strong> posed tooling-related hurdles, which was especially evident with separate modules. While centralizing everything by hardcoding resolver addresses was an option, I aimed for an auto-detection system.</p>
</li>
<li>
<p><strong>Integrating OAuth APIs</strong> introduced complexities, especially since I was more accustomed to simpler authentication mechanisms like JWT. Testing the integration involved using the GraphQL layer and added to the perceived difficulty.</p>
</li>
<li>
<p><strong>Battling perfectionism</strong> might sound like a cliché, but it was a real struggle. It took so long for me to publish this article because there always seemed to be another item on the TODO list (that would make the project so much better and/or professional). In the end, I decided to “force-release” this article even though there are some unfinished aspects, as a way to push past that barrier 😉</p>
</li>
</ol>
<h2>TODO</h2>
<p>There's always room for improvement! Here's what's on my radar:</p>
<ol>
<li>
<p><strong>Introduce automated testing</strong>. This wasn’t yet a priority, since this is a non-customer-facing application that does not serve a critical role. However, I appreciate the comfort of working with well-tested code (being able to freely refactor and plan to invest some time in it.</p>
</li>
<li>
<p><strong>Move certain interactions (night &#x26; silent mode, webcam view) into a menu</strong>. As I'm more accustomed to desktop-oriented applications, deciding on the best approach for triggering/displaying the menu is still up in the air.</p>
</li>
<li>
<p><strong>Find out a better way to store MQTT-related secrets</strong> rather than a <code>.gitignored</code> <code>.ts</code> file. This issue is especially frustrating when setting up the development/build environment on a new machine.</p>
</li>
<li>
<p><strong>Apply refactors across both server &#x26; client applications</strong>. On the client side, using React Portal for the webcam modal is a starting point, along with improving the setup in <code>main.tsx</code> &#x26; <code>App.tsx</code> is on my list. On the server side, renaming <code>externalSchemas</code> into <code>DTO</code> would be fitting, as well as a few changes in tooling - better code generation from GraphQL schemas.</p>
</li>
</ol>
<h2>Conclusion</h2>
<p>The IoT Dashboard isn't just a project — it's a constant companion throughout my career journey. With its modular design and efficient data handling, I'm proud of how far it's come. But perhaps most importantly, I am proud because I use it in my everyday life 😁</p>
<p>Stay tuned for more tech insights and stories from my journey in the world of software development. Until next time, keep coding and exploring! 🚀👨‍💻</p>


The Architecture Behind the IoT Dashboard

<h2>Presentations</h2>
<p>There were several noteworthy presentations throughout the day, but two, in particular, left a lasting impression on me.</p>
<p>First up was Aleksandra Sikora's talk titled "Turning Your Code Inside Out". Ola was live-coding an interpreter for a new language called OLang (a clever play on her name). This was a super-refreshing departure from the usual frontend/backend development. Plus, it was eye-opening to witness the power of GitHub Copilot in action.</p>
<p>The next presentation that really resonated with me was "Supply Chain Security: Risks and Open Source Tools to Assist" by Jossef Harush Kadouri. It shed light on the critical aspect of paying closer attention to project dependencies and utilizing tools like <a href="https://github.com/os-scar/overlay">Overlay</a> (overlays information about packages suggested on StackOverflow), <a href="https://deps.dev/">deps.dev</a>, <a href="https://snyk.io/advisor/">Snyk Advisor</a> (dependency comparison tools). A valuable lesson for anyone involved in software development.</p>
<p>I'd also like to give a shoutout to Illia Mishkin for his lightning talk on "Monorepo computation cache (self-hosted Nx Cloud alternative)". Although Illia seemed a bit nervous, it was evident that he had spent considerable time and effort researching the topic. The insights he shared were incredibly informative.</p>
<h2>Organization</h2>
<p>The conference's organization left little to be desired. One aspect that stood out to me was the hosting format. After each presentation, the host engaged in a sit-down discussion with the speaker, eliminating awkward moments of them standing around aimlessly. What's more, questions for the speakers were collected throughout the presentations via an online system accessible by scanning a QR code. Attendees could also vote for the best questions, adding an interactive element to the Q&#x26;A sessions.</p>
<h3>Pricing</h3>
<p>The meet.js conference is known for it's affordability. First-wave tickets were a steal at 100PLN (approximately 23USD), and even the second-wave tickets were reasonably priced at 200PLN (roughly 46USD). The registration fee also covered a lunch (tons of pizzas - nobody went hungry). Additionally, attendees could brew coffee at the available coffee machines. If that wasn't enough, if you craved snacks or barista-made coffee, the cinema's cafeteria was open.</p>
<h2>Conclusion</h2>
<p>I'm genuinely pleased that I attended the conference and can say that I'm looking forward to the next annual summit. Rumor has it that it might take place in Bielsko-Biała. I've got my fingers crossed, hope to see you all there!</p>


meet.js Summit 2023 - Wrocław

<p>Recently, I revisited the captivating universe of Star Trek, this time with "Star Trek: Strange New Worlds" (SNW). Before starting the journey to the (literal) uncharted territories of SNW, I watched "Star Trek: Discovery" (DISCO) - a series I started a few years ago. While DISCO's early seasons had my interest and left me somewhat enchanted, the further the show went, the more it seemed to slip through my grasp.</p>
<p>On the flip side, SNW kept me eagerly anticipating each episode. I even convinced my girlfriend, who isn't a big sci-fi or (maybe especially) Star Trek fan, to watch it together. Her excitement is a testament to the show's great quality.</p>
<p>So, let's dive into what sets SNW apart from DISCO and assess their places within the Star Trek universe.</p>
<p><em>Note: This review may contain minor spoilers for Star Trek: Discovery and Star Trek: Strange New Worlds, primarily confined to the pilot episodes.</em></p>
<p><em>Note 2: Star Trek is a series of science fiction movies and TV series, first released in 1966 and continuing to this day. Set in 23rd century, Star Trek focuses on the theme of exploration of the cosmos and seeking out new civilizations.</em></p>
<h2>Discovery</h2>
<p>DISCO was my gateway into the modern Star Trek productions, leaving a permanent mark on my perspective. Frankly, I have mixed feelings towards "Discovery". If I were to rate it, I'd settle on a solid 6.5 out of 10. Here's why.</p>
<h3>Characters</h3>
<p>DISCO features an impressive main cast, including notable actors like Sonequa Martin-Green (Michael Burnham), Doug Jones (Saru), Anthony Rapp (Paul Stamets), and in the earlier seasons, Jason Isaacs (Captain Gabriel Lorca) - whose performance I found particularly engaging. These actors deliver standout performances that resonate deeply with me. I am especially fascinated by their ability to capture the complexity of moral dilemmas, especially within the context of the war.</p>
<p>However, my enthusiasm waned as I noticed a stark disparity in character development. While it delves deep into the lives of its central characters, the supporting crew members, especially those on the bridge – the beating heart of any starship – remain woefully underdeveloped. It's a missed opportunity that leaves the ensemble feeling incomplete.</p>
<h3>Trekkiness</h3>
<p>DISCO boldly departs from the traditional "adventure-of-the-week" format that defined earlier Star Trek series. Instead, it takes on a more serialized storytelling approach, where episodes are intricately interconnected, forming a cohesive, season-long narrative arc. While this shift has merits and aligns with modern TV trends, it sometimes overshadows the episodic adventures that made Star Trek a beloved watch. It's a double-edged sword that adds depth to the overarching storyline but occasionally sacrifices the essence of standalone exploratory missions. I like this approach, but it's worth noting as different.</p>
<p>Perhaps the biggest issue among Star Trek fans is how DISCO handles the "sacred" canon of the franchise. Set in a time before the events of "Star Trek: The Original Series" (TOS), however, it introduces technologies and relationships that, in theory, should not exist in that era. For instance, the series presents Michael Burnham as the sister of Spock, a (main) character from TOS, despite Spock never mentioning her. DISCO attempts to justify these discrepancies by invoking classified information. To many fans, this feels like a convenient narrative loophole. It's a creative choice that has ignited passionate debates among Trekkies.</p>
<h3>Story</h3>
<p>DISCO's storyline revolves around the USS Discovery, a previously unknown Starfleet flagship, introducing multiple captains throughout its course. The series takes on a very dark turn, where it depicts, for the most part, a war-centric narrative. "Discovery" makes a significant shift in tone from the classic Star Trek.</p>
<p>The decision to tightly interlink episodes contributes to this shift, forming the narrative arc centered on the theme of war. Initially, I appreciated how the show presents existential problems within this war storyline. However, as each season concluded with galaxy-threatening events, it quickly began to wear on my engagement. Nevertheless, the initial seasons still offer intriguing and captivating elements.</p>
<h2>Strange New Worlds</h2>
<p>SNW feels like a solid return to the classic Star Trek essence. I found myself thoroughly enjoying its style, format, and writing. I would give it a well-deserved rating of 8 out of 10.</p>
<h3>Characters</h3>
<p>SNW centers its narrative around the voyages of the USS Enterprise commanded by Captain Christopher Pike, brilliantly portrayed by Anson Mount. Set just a few months after the events of "Discovery" and several years before The Original Series (TOS), SNW reintroduces us to beloved characters from TOS, including Spock (Ethan Peck), Nyota Uhura (Celia Rose Gooding), and Christine Chapel (Jess Bush) among others.</p>
<p>In my view, Anson Mount shines as the charismatic Captain Pike, epitomizing the true spirit of a Starfleet captain who constantly strives to do what's right (in stark contrast to Captain Lorca from DISCO). In particular, Ethan Peck's performance as Spock stands out, as he masterfully navigates the character's nature. Spock's journey involves a profound shift from a purely logical perspective to embracing emotions and ultimately returning to a perspective grounded in pure logic. These character arcs are portrayed with exceptional skill.</p>
<p>After two seasons of SNW, I can confidently say that I feel intimately connected with all the main characters, including the entire bridge crew. Their backstories and development are diligently explored, drawing viewers like me deeper into their lives. This ensemble execution captivates me and keeps me invested in the show.</p>
<h3>Trekkiness</h3>
<p>SNW embodies the essence of Star Trek, upholding the canon and crafting backstories that align seamlessly with the series' rich history. It entails tasks like ensuring characters stay true to their origins or including subtle nods to fans, like references to technology that changes (communicators, weapon systems). I truly appreciate the attention to continuity.</p>
<p>Strange New Worlds rekindles the classic "adventure-of-the-week" format. Each episode is centered on individual missions that propel the overarching narrative forward. It strikes a harmonious balance in this execution and encapsulates the essence of Star Trek. Achieving this is no small feat, yet SNW accomplishes it gracefully.</p>
<p>Some episodes employ traditional Star Trek shooting techniques, evoking a sense of nostalgia. Spock's trademark eyebrow raise (and the sound!) makes its appearance, and the series even features a crossover with "Star Trek: The Lower Decks" - an animated show set far in the future of the Star Trek timeline.</p>
<h3>Story</h3>
<p>The story primarily follows the USS Enterprise under Captain Christopher Pike's command. Drawing from the foundations of "Star Trek: The Original Series" (TOS) and glimpses of the future seen in DISCO, we already know that Captain Pike is destined to meet his end in a tragic accident, heroically saving many children, a fact that plays a significant role in the plot.</p>
<p>This element adds depth to the storyline. Pike knowingly undertakes risky missions, confident that his fate won't change. He also contemplates the concept of destiny. Pike questions whether he can alter the course of the future or if he is merely an observer on a preordained journey. This twist offers insight into character development, revealing their thought processes, decision-making, and growth.</p>
<p>Without revealing spoilers, I won't delve further into plot details. However, I have a preference for slightly longer seasons. Extending the season from 10 episodes to 12 or even 14 episodes would be a good idea. This adjustment would allow for more standalone episodes and deeper character introspection. Nonetheless, I understand that the constraints of modern TV production do not always allow for this - and it doesn't significantly diminish my overall enjoyment of the series.</p>
<h2>Summary</h2>
<p>I stumbled upon a comment on the internet that perfectly encapsulates my sentiments. "Discovery" while not flawless, served a crucial role in demonstrating that modern Star Trek can be commercially successful. In many ways, "Strange New Worlds" is the offspring of this endeavor — a refined show that proudly carries forward the best qualities of the originals. Whether you're a newcomer eager to embark on a Star Trek journey or a seasoned fan seeking a pleasant watch, "Strange New Worlds" has you covered.</p>
<p>On the other hand, "Discovery" has unique strengths and it is a series worth exploring - especially after delving into the "Strange New Worlds". Ultimately, the Star Trek universe continues and is always expanding. These series contribute their unique flavors to the ever-evolving cosmos of exploration, discovery, and the enduring spirit of humanity reaching for the stars.</p>
<p>If you're eager to explore these series, both are easily approachable for the newbies to the Star Trek universe.</p>
<h3>The Future</h3>
<p>"Star Trek: Strange New Worlds" has been officially renewed for its third season. However, due to the SAG-AFTRA (American labor union representing media professionals) actors' strike, the final release date remains uncertain. Speculations are pointing to a potential 2024 launch.</p>
<p>Meanwhile, "Star Trek: Discovery" is set to release its fifth and final season in 2024.</p>
<h3>Where to Watch</h3>
<p>Both these remarkable series were brought to life by Paramount, and you can catch them on Paramount+ and related streaming services.</p>
<p>In Poland, however, where Paramount+ is unavailable, you'll currently find both shows streaming on the SkyShowtime platform.</p>
<p>Happy watching!</p>


Category Personal

Hello World! Welcome to my new site!

The Architecture Behind the IoT Dashboard

meet.js Summit 2023 - Wrocław

Star Trek: Discovery vs. Strange New Worlds - Exploring Two Different Cosmic Journeys