标签：#devjournal

The thing I'm building, App Store Analyzer, is a website that does one thing: it reads an iOS niche and writes a deep market analysis for indie devs. For a long time that analysis had one brain — and it spoke German. That made sense at the start. German is my home market and my own language, so I built the analysis logic in German first. I could actually feel whether the output was good or garbage, section by section, because I was reading it in the language I think in. It got deep. Reliable. I trusted it. Then it started to hurt. Every time I wanted the analysis in another language, I was basically running the whole expensive thinking step again from scratch. German code, German slugs, German routes, German everything — and a goal of serving 14 languages. The whole thing fought itself. So I rebuilt the brain in English. Not "translated the code" — rebuilt the canonical brain so English is the one source of truth. Now the engine thinks once in native English, and that single analysis gets translated and cached into 13 other languages . Generate once, translate many. It was not a clean ride. The lows. A refactor left a pile of undefined names and quietly 500'd my detail pages — live, in production, while I thought everything was fine. I misread a normal cache warm-up window as a dead backend more than once and "fixed" things that were never broken. I spent an embarrassing stretch hammering an endpoint with a wrong key, watching 403 scroll by, before realizing my terminal had eaten the line that set the key. Small things. Hours each. The highs. Two of them I didn't expect: It got cheaper , not just cleaner. I'm not paying for a full deep analysis per language anymore — one real generation, then lightweight translations. For a solo dev watching every API cent, that's the whole game. And the English brain was actually sharper . I ran the old German output against the new English one side by side, fully expecting English to be the weaker copy. It wasn't. In a few section

GSoC 2026 | CircuitVerse × Canvas LMS LTI 1.3 Integration If Week 1 was about getting familiar with the codebase and understanding what needed to be built, Week 2 was about learning the hard way that writing code is only half the job. The other half — the messier, more humbling half — is getting that code accepted by the people who actually maintain the project. This week was full of detours, rejected pull requests, reviewer feedback that stung a little, and a surprisingly frustrating fight with a two-letter word in Ruby. But by the end of it, I had something real to show: a clean, reviewed, and submitted change to CircuitVerse that lays the foundation for the entire LTI 1.3 integration. Let me walk you through it. A Quick Refresher: What Are We Building? CircuitVerse is an open-source platform where students can build and simulate digital circuits right in their browser. The project I'm working on aims to connect CircuitVerse with Canvas, one of the most widely used Learning Management Systems (LMS) in universities around the world. The technology that makes this connection possible is called LTI — Learning Tools Interoperability. Think of it as a universal plug that lets any educational tool (like CircuitVerse) slot into any LMS (like Canvas) so that students can log in once, get assignments, submit work, and have their grades flow back automatically — all without leaving their course page. There are two versions of this plug: LTI 1.1 , which is old and uses a simpler (but outdated) security mechanism, and LTI 1.3 , which is newer, more secure, and what Canvas actually recommends today. My job is to bring CircuitVerse fully up to LTI 1.3 standards. Monday–Tuesday: A Pull Request That Taught Me to Read Diffs I started the week with what I thought was a solid pull request (PR) — a fix for a bug in CircuitVerse's existing LTI 1.1 grade passback feature. "Grade passback" is the process where CircuitVerse sends a student's score back to Canvas after they complete an as

Reflecting on two major technical challenges from my backend engineering internship, focusing on fault tolerance, infrastructure, and distributed architectures. Introduction As I wrap up my HNG internship, I’ve been reflecting on the gap between code that "works on my machine" and code that survives in production. Here is a look at two tasks from Stage 9—one solo, one team-based—that completely changed how I approach backend engineering and infrastructure. The Individual Task: Background Job Scheduler What it was For my individual Stage 9 task, I built a distributed background job scheduler backed by PostgreSQL and a FastAPI backend, featuring a vanilla HTML/CSS/JS frontend. It manages async tasks (like a mock email sending queue) using a MinHeap priority queue, Directed Acyclic Graph (DAG) dependency resolution, a Dead-Letter Queue (DLQ), and a real-time Server-Sent Events (SSE) dashboard. The problem it was solving Heavy asynchronous tasks—like email generation or batch processing—cannot block the main API thread. The system needed to successfully queue, prioritize, retry on failure, and track every job entirely independently from the standard request-response cycle. How I approached it I built the core logic from the ground up: a MinHeap and an alternative Timing Wheel algorithm for scheduling, a worker engine featuring a 3-attempt backoff sequence (1s, 5s, 25s with jitter), a DAG dependency checker, and a starvation daemon to prevent tasks from hanging. Once the CRUD API and SSE streaming were hooked up, I containerized the entire application with Docker and wrote my deploy scripts. I thought I was done. What actually broke and how I fixed it The application code took hours. The deployment took a full day of non-stop debugging across multiple cloud providers. Oracle Cloud was out of capacity on every free tier shape, and GCP demanded upfront payment. I finally got a t3.micro running on AWS, but that’s when the real DevOps nightmare began: The SSL Chicken-and-Egg

The biggest lessons I learned from open source contributions weren't found in the code itself. Communication, collaboration, and workflows matter more than I expected. For a long time, I hesitated to contribute to open source. Part of it was because I assumed that contributing meant writing code. As a self-taught developer, that felt intimidating. The other part was "Git anxiety." Forks, branches, pull requests, merge conflicts, and CI checks all seemed like a lot to understand before I could even make a contribution. Eventually, I started small. Instead of focusing on code, I looked for opportunities to improve documentation, README files, and learning materials. What surprised me was that writing the actual change was often the easy part. Most of my learning happened outside the code itself: understanding contribution guidelines, repository workflows, automation, and review expectations. Over time, I realized that modern open source contribution is about much more than just writing code. Contribution Model Has Changed When many people think about open source contributions, the mental model is still fairly simple: Find Bug ↓ Write Code ↓ Open PR In reality, I realized that most modern repos involve much more than that. Before making a change, contributors often need to understand project workflows, CI pipelines, automated checks, contribution guidelines, and review expectations. The code change itself might only take a few minutes, while understanding how the repo operates can take much longer. A modern contribution often looks more like this: Understand Repository ↓ Understand Workflow ↓ Understand Automation ↓ Make Change ↓ Open PR ↓ Respond to Review It looks intimidating, but I think this flow helps projects stay maintainable as communications grow. What I've learned from contributing to different projects is that open source is not just a coding skill. It's also a collaboration skill. The faster you can understand how a project works, the easier it becomes to

Anyone working with several projects and an AI assistant knows the problem: in every repo you explain anew how you name things, what the layer architecture looks like, why you deliberately don't use this one library. The decisions were made long ago. But they live in your head, scattered across repos, and the assistant only ever knows the slice it currently sees. So I started putting that knowledge in one place where both I and Claude can find it. Why Outline – and why self-hosted The choice fell on Outline , self-hosted on its own subdomain. Three reasons tipped the scales. First: I want to keep my data with me and not depend on a vendor. A knowledge store that all my decisions flow into over the years is exactly the kind of asset you don't want in someone else's hands. Second: full data export, any time. If I want to move to a different system tomorrow, I take everything with me. No lock-in. Third: self-hosting opens up better options later – for instance my own RAG, should I ever want to go deeper into searching across my own body of knowledge. I don't need it right now. But the door is open, and that's worth the effort. The cookbook – the heart of it Separate from the individual projects sits its own collection: the cookbook. Cross-project, generic, and that's exactly what makes it valuable. This is where it says how I build, regardless of which product I'm sitting at right now. Roughly, it's split into a few areas: Conventions – naming, code style, docblocks, git commits, markdown, package manager, writing style. The boring but decisive things you'd otherwise re-discuss three times per project. Backend – layer architecture, a unified API error format, test strategy, migrations and indexes, i18n, async jobs and idempotency. Frontend / mobile – feature-first architecture ( core/ , shared/ , features/ ), design system, forms, networking, state, routing, storage, styling, testing. Deployment – my standard setup with Caddy as the edge and a Hetzner VPS. Templates –

No trabalho, nenhum código mudou. O que mudou foi a forma como os clientes inserem os dados. E isso quebrou coisas que nenhum teste existente pegou. O bug que só aparece quando alguém usa A motivação pra montar E2E do zero veio de um problema específico. Você precisava acessar a aplicação pra quebrar. Não era um erro de lógica isolado que um teste unitário pegaria. Era uma combinação de dados reais num fluxo real produzindo um resultado errado que só aparecia na tela. Os clientes chegavam lá antes da gente. É uma categoria de problema que teste de código não resolve, porque o problema não está no código. Está na interação entre o código, os dados e o ambiente. A forma mais rápida de pegar antes é rodar o fluxo completo do jeito que o usuário roda. Ficou com smoke tests cobrindo os principais fluxos do produto, configuração pra rodar contra múltiplos ambientes, e notificação no Slack quando o nightly quebra. A parte mais útil não são os testes em si. É saber antes do cliente reportar. Autocrop: quando nenhuma ferramenta resolve tudo Num projeto paralelo que mantenho, passei o fim de semana montando autocrop automático pra imagens. A ideia inicial era usar o imgproxy Pro, que tem detecção de objeto embutida. Não ficou preciso o suficiente pra variedade de imagens que eu tinha. Fui pro Rekognition, que retorna bounding boxes. Mais controle, mas bounding box tem um limite: é um retângulo. Objetos não são retângulos. Aí descobri o rembg, que faz algo diferente. Em vez de delimitar uma área, ele cria uma máscara pixel por pixel usando uma rede chamada U2Net, treinada pra segmentação de primeiro plano. O resultado foi bem superior — ele recorta o objeto, não uma caixa em torno dele. Colocar isso em Lambda foi onde a semana ficou mais lenta. O modelo precisava estar acessível pro processo do Lambda, coloquei em /root , Lambda não lê de lá. Movi pro /opt , chmod 755. O NUMBA tentou escrever cache em diretório read-only, defini NUMBA_CACHE_DIR=/tmp . Depois OOM em imagens mai

Hello Dev.to Hello everyone, This is my very first post here at Dev.to. I am curious about how companies go about running their business in the backstage and, specifically, what kind of challenges do they face in their inventory management, warehousing, workplace technologies, and overall business systems. There have been plenty of times that I witnessed how little operational inefficiencies turn into big business problems when left untreated for too long. I intend to share my observations and learnings regarding the topics of inventory management, asset management, workflow improvement, and business systems used by companies to keep themselves organized and efficient. Please note that I am not here to pretend having all the right answers. It's simply an attempt at learning and exchanging ideas within the industry. See you around!

I work on a computer all day. Multiple projects, lots of switching, constant interruptions. A while back I noticed I was losing track of my own work. Not really the big things but mostly the small stuff. The decision I made on Tuesday about why I structured something a certain way. The thing I was halfway through when a Slack message pulled me away. The task that never made it onto any list because it felt too small to write down (but I ended up forgetting about after lunch until 2 days later). By Friday I'd look back at the week and genuinely struggle to piece together everything I actually did. I tried obsidian (and still actively use it). I also tried just being more disciplined. None of it fully stuck because the friction of capturing things manually meant I only ever captured the stuff I already remembered. The messy ad-hoc stuff that actually eats a lot of my time never made it anywhere. I'm curious if other people deal with this. Not the big project management stuff because that's mostly solved, but rather, the stuff in between. The context that lives in your head and disappears the moment you get interrupted. How do you handle it?

Hello everyone! It has been a busy week, but I've made some exciting progress on my machine learning journey. Here is what I've been up to: Kaggle Orbit Wars & AWS I completed the baseline implementation for the Kaggle Orbit Wars competition and initially hit a score of around 1030. My score has dipped slightly over the past few days, so I am currently brainstorming ways to improve it. This week also marked my very first time using AWS! I used it to extract data for reinforcement learning. Transparency check: I spent exactly $7.58 USD on AWS resources during the process. Paper Reading & RL Insights I spent a lot of time reading research papers this week. AlphaZero: I was initially excited about using the self-play mechanism from AlphaZero. However, because this specific game has rock-paper-scissors dynamics, standard self-play might not work effectively. AlphaStar: This led me to the AlphaStar paper, which uses self-play combined with League Training . The engineering behind AlphaStar is incredible. Two specific concepts really stood out to me: Pointer Networks and V-trace off-policy correction . I was also impressed by their use of an LSTM core to handle long-term memory. Next Steps Moving forward, I plan to leverage Kaggle, AWS, and GCP credits to train different components of my model. I am giving myself total freedom to experiment, imagine, and test unconventional solutions. Random life update to close out the week: I used to have long hair because I was insecure about my forehead, but I finally decided to shave it all off at home by myself. It honestly feels really weird right now, but it's a fresh start!

My Journey Towards AI and Software Development Hello everyone, My name is Kunal Tiwari, and I am a student who is passionate about technology, artificial intelligence, and software development. Technology has always fascinated me because it allows people to transform ideas into real-world solutions. Over time, I developed a strong interest in understanding how software is built and how AI can help solve everyday problems. I started exploring programming and software development with curiosity and a desire to learn. Although I am still at the beginning of my journey, I believe that consistent learning and practical projects are the best ways to grow as a developer. My current interests include: Artificial Intelligence (AI) Android App Development Software Engineering Problem Solving Building useful applications Through this blog, I plan to share my learning experiences, projects, challenges, and lessons that I discover along the way. My goal is not only to improve my technical skills but also to document my progress and connect with other learners and developers. I know the journey ahead will require patience, dedication, and continuous learning. However, I am excited about the opportunities that technology offers and look forward to building meaningful projects in the future. Thank you for reading my first post. I hope to share valuable insights and experiences as I continue my journey towards AI and software development. Best regards, Kunal Tiwari

Hey Folks! 👋 Good Day... This blog is a summary of the concepts covered during the last two classes at my institute. One of the reasons I enjoy writing these blogs is that they serve as my personal knowledge journal. Whenever I need a quick refresher on a concept, I can simply revisit my blog instead of searching through notes or recordings. It helps me reinforce what I've learned while also documenting my learning journey. Over the past two days, we explored several important Java concepts, including constructors, the this keyword, inheritance, constructor chaining. In this blog, I'll share what I learned in the simplest way possible, using real-world analogies, practical examples, and the thought process that helped me understand these concepts more clearly. If you're a beginner learning Java, I hope this walkthrough makes these topics a little easier to grasp and a lot more memorable. What Is a Constructor? According to Oracle Java Documentation: A constructor is a special method that is used to initialize objects. The constructor is called when an object of a class is created. In simple terms: Imagine you order a new smartphone. Before the phone reaches your hands, the factory installs the operating system, configures the hardware, and prepares everything for use. A constructor does exactly the same thing for an object. Before you use an object, Java uses the constructor to prepare it. My First Confusing Example I wrote the following code: public class SuperMarket { String name = "python" ; int price ; public SuperMarket ( String name , int price ) { System . out . println ( "Are you constructor?" ); name = name ; price = price ; } public static void main ( String [] args ) { SuperMarket product1 = new SuperMarket ( "abc" , 20 ); System . out . println ( product1 . name ); } } I expected the output to be: abc But Java printed: python And honestly... I was completely confused. After all, I passed "abc" into the constructor. Why was Java ignoring it? The Hotel Roo

Hello Dev Community! 👋 It is officially Day 12 of my journey to master the MERN stack! Today, I wrapped up Lecture 3 of Apna College's JavaScript playlist with Shradha Didi, focusing on a fundamental data type we use every day: Strings . Before today, I thought strings were just plain text wrapped in quotes. Today, I learned how much power JavaScript gives us to manipulate, slice, and dynamically format text. 🧠 Key Learnings From JS Lecture 3 (Strings) I explored how JavaScript handles text strings and the built-in properties and methods that make text manipulation effortless: 1. Template Literals (The Ultimate Game Changer) Shradha Didi introduced Template Literals , which use backticks ( ` ) instead of standard quotes. This allows us to perform String Interpolation —embedding variables directly inside a string using ${variable} . It makes code look clean and professional: javascript let obj = { item: "pen", price: 10 }; // Old way: console.log("The cost of", obj.item, "is", obj.price, "rupees."); // Modern way: console.log(`The cost of ${obj.item} is ${obj.price} rupees.`);

Em 2023, eu arrumei as malas e saí de Recife, minha terra natal, para morar no interior do Mato Grosso. O motivo? Cursar Ciência da Computação. Eu sabia que enfrentaria um choque cultural, o calor do Centro-Oeste e a saudade de casa. O que eu não imaginei é que o maior desafio seria a sensação constante de que eu era uma fraude no meio da minha própria sala de aula. Se você estuda ou trabalha com tecnologia, provavelmente já passou por isso. Você senta na primeira semana de aula e parece que metade da turma já programa desde os 12 anos, fala termos técnicos que parecem outra língua e discute sobre ferramentas que você nem sabia que existiam. Hoje, na reta final da graduação, focando meus estudos em Back-end e Dados, quebrando a cabeça com Go, Python e SQL, eu olho para trás e vejo o quanto essa cobrança silenciosa quase me paralisou. Se você está sentindo que entrou no curso errado ou que todo mundo corre a 100 km/h enquanto você ainda está engatinhando, pega um café e vem ler este papo reto sobre como lidar com a tal da Síndrome do Impostor. O "efeito vitrine" e a falsa ilusão de que somos os únicos perdidos Na faculdade de TI, a comparação é quase inevitável. A gente abre o LinkedIn e vê o colega conseguindo estágio internacional; abre o GitHub e vê códigos impecáveis; na sala de aula, sempre tem quem responda às perguntas do professor antes mesmo dele terminar de falar. O erro está em achar que o ritmo do outro deve ditar o seu. Na Computação, as pessoas vêm de bagagens completamente diferentes. Quem já sabia programar antes da faculdade pode ter facilidade em Lógica de Programação, mas talvez sofra tanto quanto você quando chegar a hora de aprender Álgebra Linear ou Teoria da Computação. Sentir-se perdida não significa incompetência; significa apenas que você está no processo de aprender algo complexo. E adivinha? Todo mundo ali está tentando descobrir como as coisas funcionam, mesmo quem finge que sabe tudo. O que me ajudou a virar a chave Eu não acordei um dia

Introduction Since I started publishing articles on Dev.to, I've been working on a personal project to transform my old blog website—which is no longer actively maintained—into a portfolio site ♻️ As part of that project, I recently started learning Figma and UI design🎨 When I discovered Figma MCP , I imagined a future where generative AI could automatically create polished, modern, and visually appealing designs for me with minimal effort 😎 Unfortunately, reality turned out to be quite different . This article is a reflection on that experience and a reminder to my future self about what I learned along the way📝 TL;DR I wanted to design a portfolio website in Figma , but quickly realized that UI design was more difficult than I expected. I wondered whether using Codex and Figma MCP would allow me to outsource the design process to AI , so I decided to try it. I couldn't magically generate the polished design I had imagined while also maintaining a well-structured Figma file with globally managed variants and reusable components. I learned that defining design rules first and building components step by step helped produce results that were much closer to my original vision. Even then, the process was not dramatically easier than expected, so I eventually decided to keep things simple and build my portfolio around the design principles already provided by shadcn/ui . What I Tried with Figma MCP🎨 While planning the UI design for my portfolio website , I initially created simple wireframe-like layouts in Figma to explore the overall page structure and component placement before working on detailed designs. At first, I wanted to keep things simple. However, as I continued working on the project, I found myself wanting something more polished, more modern, and ultimately more impressive . The problem was that I have very little confidence in my design skills. I'm an in-house IT engineer, not a professional developer or designer, so I often struggle to judge what makes a

I build a security platform. Last night I stopped adding features and did something less fun and more honest: I sat down to make every capability prove it actually works — end to end, with real data, demanding a real pass or fail. "It ran" is not a pass. A page that renders is not a feature. A green checkmark is a claim, not evidence. So I went capability by capability and tried to break each one. I found four real bugs and one of them was a gut-punch: a whole detection engine that was wired into the UI, unit-tested, and never actually ran in production. Here's how the night went. The rule: drive it, don't admire it My method was boring on purpose. For each capability: Feed it real input through the real entry point (CLI or API), not a test fixture. Check the data actually landed (query the DB, don't trust the success message). Feed it a malicious input and a benign input — it has to fire on one and stay quiet on the other. The detection engine passed cleanly. I threw a PsExec process event at it and it lit up: $ zds-core detection eval --event '{"event_type":"process_create","process_name":"psexec.exe"}' 1 alert ( s ) : [ high] PsExec Execution — ( matched: map[process_name:psexec.exe] ) A wevtutil cl Security event tripped a critical "Log Clearing" rule. A plain notepad.exe matched nothing. Good — it detects, and it doesn't cry wolf. (Small UX papercut I fixed while I was there: if you forgot the event_type field, the engine silently matched nothing and printed "no rules matched" — which reads exactly like "you're safe." Now it warns you that the event can't match any rule. Silence that looks like safety is the most dangerous output a security tool can produce.) The one that hurt: ITDR Identity Threat Detection and Response. The engine has detectors for impossible travel, credential spraying, brute force, privilege escalation. All unit-tested. All green. I ran the real flow: POST two login events for one user — New York, then London thirty minutes later. That's ~5

In May, I continued my "One Commit a Day" Challenge and spent more time contributing across different open-source projects. Compared to April, I was able to contribute a bit more and explore a wider variety of repositories. Repositories That Stood Out Some of the projects that left the biggest impression on me were: python-odpt Huggin Face Context Course Human Signal ML ScribeSVG A Stable Checkpoint One milestone I was happy about this month was reaching a stable checkpoint for my Tokyo MCP Server project. It is still a work in progress, but getting to a point where the project feels stable enough to build upon was a satisfying moment. Documentation Matters Another contribution that stood out was helping improve a python-odpt README documentation . It wasn't a large technical contribution, but it reminded me that making a project easier for others to understand can be just as valuable as writing code. Good documentation lowers the barrier for future contributors. Sometimes, a clearer README can help more people than a small code change. Learning Beyond Python One practical lesson I learned this month was that being a Python-focused contributor doesn't mean I can ignore the JavaScript ecosystem . While working with different repositories, I finally installed Node.js and started using npm . Many modern open-source projects rely on TypeScript-based tooling, build systems, or development workflows, and understanding those tools makes contributing much easier. The Biggest Challenge: Finding Information And Communication Matters The biggest challenge I faced wasn't coding. It was documentation. Every repository has its own way of organizing information. There are definitely common patterns, but every project also develops its own style over time. Sometimes the information I need is in the README. Sometimes it's in a wiki. Sometimes it's buried in a docs folder several levels deep. And sometimes it's spread across all three. Open Source Is Also About Navigation As a contri

Daily Learning part twenty-two. I haven't been active in three days due to Eid Al‑Adha. On Tuesday I went to my family house, where we go once in a while. We call it the family house because that's where my grandmother, uncles, aunts, and cousins live. I didn't bring my laptop with me because I wanted to spend some time with my family, which I haven't done in months. I stayed there for the two days of Eid. Today I came back by bus. I was supposed to arrive at 17:00, but due to traffic I arrived at 18:40. When I arrived I ate a small sandwich and got back to work. I started the session at 19:30. The first thing I did was complete the HTML Tables section. It was difficult to learn (at least for me). It covered HTML Tables, Table Borders, Table Sizes, Table Headers, Padding & Spacing, Colspan & Rowspan, Table Styling, Table Colgroup, Exercises, and finally the Code Challenge. Then I did a quiz and the Unit 2 test in Khan Academy and also completed one lesson in Unit 3. Now I have started a Tic‑Tac‑Toe challenge in Python. I watched a video on the minimax algorithm, which the game uses. I have started coding, but I am far from finishing it. I am ending today's session at 23:40. Eid Al‑Adha Mubarak to all Muslims. "Speak good or remain silent." Prophet Muhammed (peace be upon him)

Hey everyone! I bring you my development journey on what I have discovered, accomplishments for this...

🗓️ This Week Completed two more sections of the SwiftUI tutorial 🦾 As I continue working through the tutorial, I can feel my understanding of SwiftUI fundamentals becoming more solid 🔥 It was my first time posting a standalone article about reverse engineering📝 If you're interested, feel free to check it out 👇 A Curious Journey Into Reverse Engineering an AI-Generated Python .exe Umitomo Umitomo Umitomo Follow May 26 A Curious Journey Into Reverse Engineering an AI-Generated Python .exe # beginners # reversing # security # python 5 reactions Comments Add Comment 5 min read I started creating UI designs for my future portfolio website in Figma. I was able to roughly sketch out the overall structure of the site, but I also realized how difficult it is to create modern and stylish UI designs. (It really made me realize I don’t have much design sense yet 😂💦) While struggling with the design process, I came across several articles about Figma MCP . That made me interested in exploring how generative AI could help with UI design ideas, so I decided to start researching Figma MCP further. Completed Securing AI Systems room from the AI Security Learning Path on TryHackMe this week🤖 📱 iOS (SwiftUI) Worked through the SwiftUI tutorial and completed "Create an Algorithm for Badges" and "Add inclusive features" 🌐 Web Development Posted my weekly dev log on Dev.to and a standalone article about my first attempt at reverse engineering 📝 Created rough portfolio website UI layouts in Figma Used shadcn/ui component library design templates in Figma Started learning UI design in Figma using community resources 🔐 Security (TryHackMe) Completed Securing AI Systems room (part of the AI Security Learning Path) on TryHackMe. 💡 Key Takeaways 📱 SwiftUI Learning Add inclusive features Learned that SwiftUI automatically adapts UI elements for Light and Dark Mode by default. Learned how to preview and compare Light and Dark Mode layouts in the Xcode canvas. Understood that system-provided sema