Hey everyone! Here’s my latest update from the world of programming, where things are a bit quieter this week, thanks to the bustling Black Friday/Christmas season. You know how it is – everyone’s in a whirl, especially at a company that makes fitness machines. The flood of tickets is more like a gentle stream right now, which is a good thing! I’m learning that being a team player in programming isn’t just about fixing all the bugs yourself, but also about collaboration and sharing opportunities. So, I’m resisting the urge to scoop up all the tickets!
A little while back, I tackled a Spotify API token bug and got asked why I revamped the entire authentication process. Well, for those following my Bachelor’s degree capstone project, you might have seen my blog posts on FieldFab and peeked at its code on GitHub. Fun fact: I’ve rewritten FieldFab’s codebase thrice, each version outdoing the last. My journey from the tight-knit, feature-stacking version in 2020 to the sleek, modular FieldFab v3 has been quite an adventure. With iPadOS’s Stage Manager, FieldFab had to adapt to various screen sizes and aspects, so modularity became key. Seeing the Spotify ticket, I got flashbacks of FieldFab v1 – hard to navigate and ripe for a revamp. Hence, I separated authentication from using Spotify’s API, embracing modularity.
This solution was inspired by concurrency, a concept I grasped better after watching a lecture by the creator of the Go language. He differentiated between concurrency and parallelization. It’s like this: imagine Gophers (the Go language mascots) working in assembly-line fashion. They could do tasks sequentially or split the work, each handling a part – that’s concurrency. So, that’s the approach I took with the Spotify issue, and it worked like a charm!
Apart from that, I revisited FieldFab for the first time in months. Post-iOS 17, I found a couple of bugs – a wonky 2D workshop view and some export to PDF glitches. All fixed now, and FieldFab V3.0.7 is up and running on the App Store! I’m also tinkering with my SIMDExtensions library, a wrapper for Apple’s simd framework. It’s all about making simd more Swift-friendly, turning complex C functions into easy-to-use, type-specific extension methods. I’m expanding it to include Integer types – no immediate need for them on my end, but hey, it’s all about creating a comprehensive tool, right?
So, while I wait for more tickets to roll in, I’ll be busy with my library. It’s quite the undertaking, but I’m up for the challenge.
Thanks for joining me on this journey, and stay tuned for more updates!
