There is a lot to get through so let me just start.
The Microservice Nobody Warned Me Would Be This Annoying to Build
So this whole thing started from the job. We work with multiple freight vendors. Each of them sends rates and pricing data in Excel files. And these Excel files are a mess. Not in the sense that the data is wrong. In the sense that every vendor has their own idea of what a spreadsheet should look like. Different column positions, different header names, different formatting decisions. One vendor puts the price in column H. Another puts it in column J. One calls it "Rate", another calls it "Price Per KG". You get the idea.
The job this microservice had to do was simple in theory: take an Excel file from the user, convert it into a canonical form that our system understands, and then load that canonical data into the database. Three steps. Straightforward on paper.
The hard part was step one and two. Parsing.
I built this with FastAPI and Python. The parsing logic reads the Excel file, maps columns to the expected fields, normalizes the data structure, and hands it off to the DB loader. I also added status updates along the way so the frontend isn't just staring at a spinner wondering what's happening. You get real-time feedback on what stage the processing is at.
The thing that works right now also has an asterisk next to it: everything is hardcoded for specific vendors. If vendor A always puts price in column H, I've written that assumption into the parser for vendor A. If vendor B always uses a specific row for headers, same thing. It works. But it's brittle in a way that I'm not proud of yet.
What I actually need is a smarter parsing layer. Something that can look at a file it's never seen before and figure out the structure on its own. Maybe using some heuristics about which columns contain numeric data that looks like prices, which rows look like headers, what the column names actually say. There's a real problem here around Excel file variability that I haven't fully solved yet. The current implementation is a working proof of concept, not a finished solution. And I think being honest about that distinction matters.
The good news is the pipeline itself works. File comes in, gets parsed into a canonical shape, gets written to the database. Status updates fire throughout. The architecture is solid. The parsing logic just needs to get smarter.
A Detour Through Rust
Before I ended up going full SwiftUI, I spent some time with Rust. Specifically, I wanted to understand Tauri because the plan was to build a desktop utility tool and Tauri uses Rust under the hood.
I installed Rust on my system for the first time. And then I hit the version mismatch problem. Tauri had its own requirements, the Rust toolchain I had wasn't quite right, there were some configuration things I had to sort out. Took a while to actually get the app to compile and run.
Once it was running I built something extremely small. A micro-level tool that did the basic thing I wanted it to do. But the experience of getting it to look and feel like a native Mac app was a wall I kept running into. Things that should have been simple weren't. Some features weren't working the way I expected. The visual fidelity wasn't there.
So I made a call. If I'm going to build for Mac, I should probably just learn SwiftUI properly. It's the actual native toolkit. It will look like a Mac app because it is a Mac app.
I switched. And I'm glad I did.
Learning SwiftUI from Apple Docs
I started from zero. The Apple documentation has these small guided projects where they walk you through the basic syntax and concepts. I went through those. State, bindings, views, @State, @Binding, the declarative way of thinking about UI. Built a few small iPhone apps just to get the syntax into my hands.
This is the part of learning that is boring to talk about but important to do. You can read about SwiftUI all you want. You have to write it. You have to break things and fix them and break them again before the mental model actually sticks.
I made three or four of these small projects. Nothing impressive to show anyone. Just me building things I already knew how to build in other frameworks, in this new language, until it felt natural.
What I Was Actually Trying to Build: Booring Notch
Here's the real reason I went down this path.
Booring Notch is a popular open source utility for MacBook users. If you don't know it, the short version is: it turns the notch at the top of the MacBook screen into something dynamic and useful, similar to the Dynamic Island on newer iPhones. It's a fairly well-known tool in the Mac community.
I wanted to add a teleprompter feature to it.
The idea was simple enough. A view inside the notch area that could show scrolling text at a pace you control. Useful if you're recording a video and need to read from a script without looking away from the camera.
But to contribute to an existing codebase, you have to understand the codebase first. And Booring Notch is written in SwiftUI. So that's how I ended up going through the Apple Docs. Not to learn SwiftUI in the abstract, but to learn it well enough to go make changes in a real project that already existed.
Once I had enough of the basics, I went into the repo and started exploring. Understanding how the existing views were structured, how state was managed, how the notch interaction worked.
And I was able to do it. I got the teleprompter view working inside the notch. It's not a finished, polished, production-ready feature. But it's there. The functionality is in. That felt like a real milestone because it was the first time I was contributing to someone else's actively used project rather than just building something in isolation.
I Can Say I'm Learning SwiftUI Now
Six months ago I would have said I'm a web developer who writes TypeScript and Python.
Now I think that framing is too narrow. I've built microservices with FastAPI. I've tried to contributed and a feature to a Swift codebase. The through line isn't a language. It's that I find a real problem and then figure out whatever I need to figure out to solve it.
The Udemy course on Swift is next. Angela Yu's iOS development course, which has a reputation for being genuinely good rather than just comprehensive. I want to get more systematic about this. The Apple Docs projects gave me a foundation. The Booring Notch contribution gave me a real-world test. The course is going to fill the gaps in between.
Mac development in particular is interesting to me. Not because I've decided this is my "lane" but because there are things you can build for Mac that don't exist yet, and building for the platform properly requires knowing the platform. I want to know it.
Urban Sketching
Okay, different kind of update.
I started urban sketching.
The reason is honestly simple. There is a point in a long coding stretch where your brain just stops producing useful work. You're staring at the same problem you were staring at two hours ago and nothing new is coming. And if you push through it you just end up writing code you'll have to undo tomorrow.
I needed something completely different. Something with no version control. Something where the output is physical and the process is slow on purpose.
Urban sketching fit. You go somewhere, you look at a building or a street or a crowded market, and you try to put what you see on paper. It's about observation more than technique, especially at the beginning. Building up the basic muscle memory. Getting your hand to follow your eye.
I've been putting my work on the Urban Sketches subreddit. And the community there is something I was not expecting. The feedback is constructive, the encouragement is genuine, and people who are clearly much better than me take time to actually respond to beginners. It's a warm corner of the internet, which is rarer than it should be.
There's also something interesting about being a beginner in public at something. I've been building software for a while now. I have opinions and frameworks and things I'm confident about. Sketching puts me back at zero. The line is wrong. The perspective is off. The proportions are not quite right. And that's fine. That's just where the learning is.
I plan to keep going with it. Not because I'm trying to become an illustrator. Because doing something with my hands that isn't a keyboard seems to help everything else work better.
What's In the Pipeline
There's a lot I haven't fully figured out yet.
The Excel parser needs to get smarter. The hardcoded vendor logic will break the moment a vendor changes their file format, which will definitely happen. I want to build something more adaptive there, though I'm still thinking through what that actually looks like.
The Swift learning continues. Booring Notch was a real project but it was also me following a codebase I didn't write. I want to build something from scratch in SwiftUI and see what that feels like.
The job is going well and the Arena dashboard is getting new features. Exams are wrapped up. I'll be back in properly once they do.
And I'll keep sketching. Whatever the week brings.
If you're building something, fighting with Excel files, learning Swift for the first time, or you've just picked up an unfamiliar skill in public and you know that particular brand of terrifying, I'd like to hear about it.