Recently, I was working on some Python code where I needed to keep track of an ordered list of functions to where I could call these functions again at any given time based upon a numeric index. Think of this situation like a list keeping track of an object by index, but instead, I wanted to keep track of a functions by index. My first thought was to try and create some sort of generic object that could manage all of these functions and the specific ordering that I needed.
Designing server architecture to support multiple applications can be a very tricky and intimidating task to take on. So many different things need to be considered when designing your first initial implementation that often times engineers will find themselves over engineering an achitecture all at once instead of building for their immediate needs and planning to scale over a period of time.
I was recently asked in a computational project to generate prime numbers to be used in public key hashing routines. The idea was that I needed to write an algorithm that finds prime numbers between a specific range and then those prime numbers would be randomly assigned to a list and then multiplied together in sequence to produce large complex numbers that would then, in turn, be concatenated together to form variations of public keys.
A topic that I have been hearing a lot about lately is the MVVM design pattern. MVVM stands for Mode-View View Model and is intended to solve some of the concerns that have resulted from using the MVC design pattern - specifically in the context of iOS. While MVVM is certainly not an iOS specific design pattern, I did conduct some further research into MVVM using iOS as my research platform because I I wanted to try and figure out if MVVM could be a design pattern that fixes some of the issues that I have run into when developing large MVC iOS applications.
This week I heard some chatter in certain iOS groups that I belong to about whether testing your iOS, macOS, watchOS, or tvOS applications provided any immediate value in the development life cycle. As opposed to developing features without testing and getting them to market right away and then iterating upon them in a highly agile methodology. Coming from a background where I like to write a lot of automated tests and system tests for software that I write, I have to admit, this point of view really made me pause for a moment to try and see the perspective from both sides.