Flutter Repository Pattern The Repository pattern is a simple one, you use a Repository to abstract away the implementation details of how to store and retrieve data. With Flutter, it can be complicated (especially when using Firestore) to implement the Repository pattern in a repeatable, testable way. I have heard from friends and other budding Flutter developers that testing with Firebase is a problem. Not so if you follow some well-known design patterns out there.
On Balance I’m training for an ultra marathon in May. Why would I do this? Because I also turn 30 this year. I don’t know why, but 30 feels like an age that I’ve anecdotally seen most decline. I don’t want to be that way. I want my daughter and others to see me still pushing for the limits of what is possible in my daily life. But what about balance in my world?
Yesterday, I somewhat implemented the Chain of Responsibility design pattern in C++. This was because I grew tired of writing code that constantly called into some C library, checked an error code, and continued on to call another function IF the error was not present. This lent itself naturally (in my opinion) to a Chain of Responsibility pattern, though I may not have implemented it perfectly.
Chain of Responsibility This design pattern can be boiled down to one idea: a chain of handlers working together to form a “super” handler of sorts.
Author’s note: If you like this post, consider supporting at patreon.com/windlejacob12. I love writing, and sharing what I’ve learned. I’d love to spend the majority of my time doing it!
I’ve been working on a contact lately with a local startup in Johnson City, to implement infinite scrolling in their application. The codebase is entirely generated via FlutterFlow, and being generated by a low-code tool it’s a ball of spaghetti.
Here is my solution to Advent of Code, Day 1:
(def input (slurp "day1.txt")) (def elf-totals (->> (clojure.string/split input #"\n\n") (map (fn [elf-row] (clojure.string/split elf-row #"\n"))) (map (fn [elf-row] (map (fn [calorie-value] (Integer/parseInt calorie-value)) elf-row))) (into ) (map (fn [elf-row] (reduce + elf-row))) (sort (fn [x y] (> x y))) (take 3))) (def answer (list (reduce + elf-totals) (first elf-totals))) It is an overuse of maps and reduces, but let’s go through it step-by-step.
I’m currently reading a book by John Ousterhout, called A Philosophy of Software Design, and this book preaches one central tenant: reducing complexity. This is something near and dear to my heart, being someone that frequently works on his own projects. Complexity can kill projects and companies entirely, because the cost of engineering new software is just too high. I’ve seen it several times, and each time I’ve wanted to rail against it.
Working on a project that I currently have, I’ve found myself needing some mutual exclusion in dealing with some hardware devices. I could have gone the singleton route, where I only keep one device representation in memory at a time, but the internet and stack overflow have both told me how I am oh so wrong for wanting that.
Thinking then about how I can support multiple devices in the future, while maintaining a single-device for now in a thread-safe manner, I’m forced to use mutexes to protect critical sections of code.
TIL how to implement a routing component using Re-frame and Reagent in CLJS. This has been one of the joys for me in using CLJS, things that seem like they would be complicated on the surface, end up being just a few lines of code. With this routing component, the key is to have the current page key as a symbol in the Re-frame state (sweet sweet re-frame.db/app-db), then to subscribe to that state in our component that does the routing.
It wasn’t that long ago that I was listening to an Indie Hackers podcast about Supabase. Supabase is an open-source Firebase alternative and so far we are absolutely loving using it for our current project. The experience has been great.
I have begun to model data in it and one of the things that I love is that you get instant API’s spun up to access that data. Supabase, knowing that many of today’s applications are client-only and not really dealing in backend code went ahead and created a really useful feature in their product.
I did an evaluation of myself late last night about where I stood as a software engineer. I graded myself on a great many things related to the development of my career and didn’t really like what I had found! Despite having been a software engineer for more than 7 years at this point, I don’t think there is really any skill category that I really stand out on. Jack of all trades, master of none really comes to mind when looking objectively back at these accomplishments and wondering what had happened.