CocoaHeadsNL Online Meetup, 21 April 2021

[Music] [Music] oh [Music] [Music] [Music] so [Music] [Music] [Music] [Music] so so [Music] my [Music] so [Music] [Music] [Music] [Music] one [Music] one [Music] [Music] [Music] [Music] [Music] [Music] so [Music] [Music] [Music] [Music] [Music] [Music] [Music] [Music] [Music] [Music] [Music] [Music] [Music] two [Music] [Music] [Music] [Music] [Music] [Music] do [Music] [Music] hi everyone welcome to this online only coco head chanel meetup thank you all for being here tonight for the people that are new to coco head chanel we are a monthly meetup group for apple developers we are part of the international coco hats and talk about anything apple related first of all we'd like to thank our regular sponsors they make it possible for us to host our meetups and to record and stream them as well we also like to point you to our apparel shop at cocohuts.now shop if you buy any of these products you help us to host these meetups today we will be giving away two jetbrains licenses for any of their products if you win you get to choose which one the license is valid for a full year you can enter the raffle by simply entering the meetings channel on the coco heads and else slack at cocohnell.slack.com if you don't have access to it yet you can use this invite link today manuel will share his ideas about reducing complexity in our code so we can create easily extendable and maintainable systems we hope you'll enjoy this talk please keep an eye on our meetup page and our social media channels for updates on next month's meetup if you don't want to miss any of our videos please subscribe to our youtube channel it's the easiest way to see every video that we publish but we also have our own tv os app where we will publish every video we hope everyone stays safe and healthy i now hand it over to manuel hey i'm manuel um and i want to make a plea for a more mind-sized software design i've worked in many different companies and positions over the last 12 years with the focus on ios development in that time i've always worked with companies that would call themselves agile with teams that would describe themselves as agile that would practice some agile mythology but it never was agile [Music] because agility is not some mythology some framework or some certification agility is the ability to respond to changes fast agility um agility is a sports term and generality has a physics term and yeah so let's not certification industry steal it if it doesn't feel agile it ain't agile simple as that so why do we need agility chain changes can be forced upon us at any time changes in our business markets and the strategic decision making of our company uh technological reasons or laws might be changed and we need to adapt to that fast maybe we just have a few days or weeks to to fulfill a certain role law if we design software with agility in mind the design should not get um in the way when it comes to the other tools that we use during uh in our agile processes also it should support cicd workflows so guys we need to be better at that and um we should maintain this agility um at any time and not only now and maybe a few months and releases down the road but not after that no during the whole life cycle of an app from uh being supported in the app store to being not supported in the app store and of course agile agility should [Music] should be done in respect to inter team processes so that also other teams or team members non-programming team members can benefit from our increased agility as well oh yeah my positive feedback loop um yeah i i do think that if if we do start doing things better then everything gets better um but yeah [Music] well probably another discussion um also a very sensitive topic so yeah why is scaling so hard i mean i've i've not met one person who says yeah that's we are agile and it's great and uh no um well i think because scaling is hard scaling knowledge work and scientific work is hard and that's what programming is if programming would be easily scalable computer would be doing it simple as that because then it also would be easily automatable but it isn't and i want to illustrate um if our team member or if our team would be of the size one uh the time to complete a project would be the time that it would take one person to code it well it makes sense quite logical not sure but many people assume from that point on um scaling would behave like that that you just divide divide [Music] the time that one person would need to finish the job uh by the number um in the team by the uh of 18 by the number of teammates but it just doesn't work that way why well i'm not the first person that tries to illustrate this so uh on the left we see a formula that um that i call the kevin henry conjecture because i do know this through kevin kevin haney i'm not sure if he uh if he came up with it but if he did uh if he did not i guess he would have named it somehow but um yeah so so this is this describes um um i think pretty well how scaling this teams works in reality and i want to explain why so again we have t1 and now we are after that we have this term in square brackets that is actually amdahl's law um which this [Music] which describes how parallelization works um because you will always have an offset during prioritization and this is expressed like this and the second term after the plus sign is communication over hate ahead times all the combination of connections between team members and and i think it describes very well and on the right i i try to illustrate this so besides the the yellow stuff that is the work um we also have um have this [Music] turkish topwa turkish turkeys um color that represents um the communication overhead and we also see the connections there they are not complete but we also see connections in the orange areas so uh there are dependencies uh of the uh in the work so not everything is paralyzable so i try to uh illustrate it like this so so it becomes clear it is not simply yeah adding more people and expecting that it will work um i've added this term p plus k equals 1 myself to express that i want to look at the relationship between the portion that is paralyzable in work and the communication overhead because i think it's quite clear that if your code is not very paralyzable you will have a lot of teens team sessions about it you will have a lot of um pairing sessions where you try to reason about the code with with colleagues so this this is all this communication will fit if we would plot it it would look like this so [Music] the y axis shows the time that it would need [Music] that would be needed to complete the project and the x axis shows the alex housing number of programmers in this project and this is a overall project so what we see is that there is a certain point here indicated by red where the curve turns around and this means that actually by adding more people to the project from that point on um the project will more likely be more more inefficient so it will slow down so by adding people you officially effectively slow down the project and a red is this point of no return and [Music] yeah you should not use this um formula to make any decision this is just for illustrate illustrative purposes only there are too much uh [Music] things going on in the real world that this could really express um what's going on in a real team but it's just the idea um of complexity that it illustrates but if we plug in some of the values we will actually see what i think is a very scary scaling behavior because if 90 percent of the work would actually be scalable even which is a lot i think by this formula a third developer would already effectively slow down the project and if you would have 10 times more per light if you can parallelize 10 times more which is expressed in the second line uh you only should assign maximum four developers to that and i mean this is a huge gap and um yeah and uh and uh um and to illustrate uh in the third line um the third row shows that even if only one per ml would not be paralyzable then you could assign 10 developers but i mean that's i don't know what a um code base would look like that so this row could actually indicate that team sizes of 10 are just not senseful in any situation and maybe some structuring would be in place but i've also plugged in some very bad numbers so and and it's quite interesting that yeah here i have not truncated the numbers but rounded to the first decimal place to show that this conjecture actually would say that even the first developer would already be beyond the red point so this is such a project of a paralyzable coat of um 20 or 10 percent and or one per ml as we see there yeah they are not viable not in teams um but i do think that many projects that i've seen in my career are in that range at least at this 20 percent so um yeah and and throwing manpower on that will only slow it down that's the issue but uh throw throwing manpower on it is the common reaction but let's also talk about um the architecture metaphor so this is a slide why i dare to give this presentation this baity title i've noticed in several of my jobs that there are that there is a danger in overstressing the architecture metaphor and um [Music] and you can see i did not point out where the architectural metaphor might be a good one in this table i point out where where it breaks and i think we need to uh we need to think about another name or another way of explaining uh what a software architecture is because i've learned especially since i started freelancing that people think that architecture is something that they have to pay extra and that it's not really needed but and that is something that is done beforehand and then executed and then doesn't contribute to the investment anymore and i mean that's just not the case for software architecture so yeah i want to point out that uh where it breaks and that i think we should give it a more appropriate name and which i in my opinion would be if we would talk about coding strategy because the strategy is very abstract at the beginning and so people cannot overstress this well yeah and and we've we we know that strategy can be very different things it can be a military strategy it can be a political strategy yeah economics strategy so um yeah people are used to this and yeah so instead of architecture i want to talk about intrinsic design and i do believe and um yeah i do believe that what you see now on the screen is the design underlying every interactive app the user interacts with the user interface which triggers the logic to recompute state and the new state is represented in the ui it doesn't matter if we are coding in functional programming structural programming logic programming or object orientated programming the underlying intrinsic design is always this and therefore i do believe that everything that reverses from this intrinsic design must be considered additional complexity and if this doesn't serve any purpose it must be considered accidental complexity and this is something and accidental complexity is what we want to avoid because accidental complexity is what creates bugs because it's something that is not designed it's something that is not under really under our control it's where the bugs live i used to say [Music] and we want to minimize it yeah i don't want to say at any cost that's not the right choice of wording but [Music] i think we should design apps that makes it hard to develop existential complexity any code that doesn't express the the intent of the apps designers so i do not mean user interface designers but all people that are involved in creating the app um [Music] if it doesn't es versus their intent and i also do believe that we have a lot of source codes we are very bad at removing codes we are afraid even though we have it under source control we are afraid of removing codes we are afraid that we hurt people's feelings when we remove codes that we do not uh find uh useful anymore yeah um and also a lot of dead codes and um one thing i also want to talk about a little bit um is what i call bandit bandits here these are things that were introduced to cope with um with flaws in in the language designs and these are for example everything to do with visibility of things of the visibility levels and for example it might be a keyword that is introduced like find on open i think everybody knows that a class that would be final from default would be much better but instead we have to finalize them or other way around on [Music] apis and patterns are band-aids because when we look closely at patterns and their sole purpose is to deal with the fact that classes which yeah are the main tool used in modern um object orientated programming don't have a concept of output so you could you cannot just um return something from a class like you can from a function instead you have to implement certain patterns um to to cope with this missing feature of a class and we have developed many many patterns to do so and i mean i think patterns are cool i mean they are fun it's always great when you learn something new but they also tend to make the code very fragile because not everybody understands every pattern in the same way or is aware of them and so it's a it's all it's also a tremendous training amount to uh to teach patterns to teams so let's have a closer look at classes so classes are certainly the most versatile types we have in our at our disposal they are mutable they offer inheritance and they offer any number of inputs because i can implement any number of method and the setter or whatever and we've talked about how outputs and patterns relate to each other but i want to point out that any of the above points mean complex mean complexity and and if if it's something we don't need in a given situation then it's accidental complexity and it might work for you um and this might not be a problem for you in the in the presence but this extra surface area might lead to deterioration in the future and maybe just because some some experienced guy is in vacation classes are pretty much unconstrained as we've seen but we know that good software design is about good constraining we know it for structured programming which actually was sorry we know it for structure structured programming um where actually the article go to consider that harmful can uh be seen as the starting point of a formalized version of that functional programming is actually uh uh [Music] was actually invented to come to constrain mutability um and uh for similar reasons oo programming was invented by constraining visibility um so fracture programming um uses a global state but immutable one while uh ooh uses a neutral state but hidden one so it's two solutions to the same problem mutable global state it's about constraining but we learn classes should not take central roles in our designs because they are too powerful because with big with with great uh with great power comes a great responsibility and and with uh and when we put uh human irrationality into the mix well it can be tricky and this is why we see um code bases deteriorate why we see our um where we see our agile processes not working the basis the base is just not given so another look at the class in comparison to a function so um this what i want to say with this one to one is that uh in a function you call a function once and it will return once uh while um with object orientation i actually should not call that yeah well we are looking at a class here while in object orientation and with classes we usually have an n2m message sending pattern i mean we have very different in different languages we have very different ideas what uh message sending is and i think a lot of languages actually do not get it very good very well um but usually um object orientation is defined as message sending and there we have an n2m relationship meaning a message sent from one object to another does not have to invoke a response while it can it can also invoke more than one response think downloading progress something like that so we actually want this communication pattern that we we know from object orientation but we also want to be as mutable as possible and we also want to be as as constrained as possible so we want to have handrails we want we want to have tracks that we can move on which uh we would actually bear we would be better suited with a function but uh function does have the wrong um relationship for uh request and response um so what's the solution the solution is actually uh something that um in at least related terms is researched since the 1890s um so predates object orientation and functional programming by a lot i guess because this is actually related to currying currying is um in metamathic is the act of splitting up multi-parameter functions into multiple functions with one parameter each and partially applied functions are very similar in that regard in that they that you can that you have a similar structure and you call those functions to different points in time and yeah so what we see here is a function create to-do list feature and it takes an output parameter as an input as a parameter and it returns an input so input and output are basically the same function type we just use different names here to indicate the the semantics that once we want to use it as an input and once we expect it to be an output i will not go into this much deeper at this point i want to show you some code later and then i will cover this so let's add this partially applied function to the mix and we actually see that we now got what we wanted so uh it uh so in the architecture that i will show you in in a bit i will use this um construct to create um the module type feature that i will show you in a bit so yeah core ui is the name of the architecture um its interface is actually a command interpreter which means that on the top level the surface area is only a function call that you can perform core ui has strict unidirectional data flow which is very helpful to keep code reasonable so to keep it mind size uh as in every good architecture the ui is uh is really uh treated as an io device so there is no um other connection between um the ui and um and the rest of the app then um [Music] message sending they um the different parts do not do do not know anything from each other they are truly separated and in car ui everything is a module and what i mean by this is that um we have at maximum one input at maximum one output we have a um and every module in core ui has a dsl um modules might share a dsl which [Music] which allows them to to to exchange messages while others have their own dsl system as this in this case it's sick it's uh supports uh separation of concern and true black boxing and uh which also leads to a lot less necessary uh unit tests core ui is based on a news case which is not something i invented but is introduced by robert c martin and his clean architecture so if you google for it use case clean architecture you will find a lot of implementations in any then use for language and a lot of documentation this is a very well understood pattern yeah um so uh this is an overview um of our core ui app um the um the top is the app call um we see really close by the ui the next level is the are the features and then the rectangle first rectangle layer are the use cases and the use cases in robert c martin's design use something called gateway and call stack and store such gateways and yeah so let's have a walk through where where i want to demonstrate how information flows through this app so in this case an event is fired from the user interface it's handed over to the app call app call the app call level only does one thing forward any message it receives to every receiver and feature it's now the ui is a receiver and the features i have explained you so so the message that comes from the ui first is sent back to the ui and then it is sent to every of the features if a feature recognizes the message it will um react accordingly and most likely create a request for a use case and when a use case is finished it will trigger sometime later the response but i want to mention that a feature might [Music] use several use cases to finish one message to to respond to one message but we will keep it with a simple case here so [Music] so the start call use case signals via a response that the call is started the calling feature then creates a new message hence it's over to the app core appqa again will inform the ui and then every feature and the circle is completed so we've went from the user interface triggers event to the logic processes a new state to the new state is a represented in the ui so it is pretty much exactly the intrinsic app design now i want to give you a little demo so this is the app i want to show you it is a simple to do app you can enter to do you can tag them and a simple journaling is kept so let's enter to do by the error okay we can also my computer is a little slow it's a five or six year old machine and the simulator sometimes wants to be a little bit hot because of this so we can add a to-do date we want to have beer for the weekend so let's go let's go shopping on thursday [Music] okay uh it knows a little bit more but i think this is enough as a presentation so now let's implement a feature request from our product owner so the feature request is that we um that we want to make a to-do item forkable so that you can take a older one and say forget and you have a copy of that and in the second requirement we also want to be able to pass in changes so that we can fork it but we can change for example the title while we forget and everything else is fought as it is i am not the fastest typer so i have prepared everything as uh in in git okay now i'm checking out the next commit and this commits should contain the basic specs for our forking for um yeah so what is the spec a spec is a kind of test and uh in this commit i've added this forking um test so let's try to run it and of course it should fail yeah so of course these tests do not work because [Music] our our to-do item sorry our to-do item doesn't know anything about yet so this is our to-do item it is a truly 100 percent um immutable data type and the way i achieve this is by by reprocessing um the data by by recreating the data for every change that needs to be reflected in this in this alter methods which are fed by with this change enum with change enum values with these ones so you can change the text the completion date and as the completion status and the due date the other values here are not cannot be changed by by the user at this point so now let's implement it and of course i have also prepared that because i'm really not the fastest typer [Music] and i want to point out the changes so we have added a change case fork here and we have added it's down here that if it is fork and it comes with assigned changes then a new item is created with a new idea with a new id so that makes it a separate distinct object while the rest stays the same and then we call alter on it with the changes that might have been passed in so of course the list also can be empty and also in this private alter function we deal with the changes so for example um if it is a fork then we always pass this we always return the changed item but if it is equal for all the content in it and the change that we just have applied have not changed anything we actually decide not to return the change item but the self item um but that's an implementation detail um yeah so maybe uh we have a look at at the test how we can use those so here we have the to do items back and here we create a to-do item and this is these are tests written with the frameworks quick and nimble and if you're not if you don't know know them have a look at them it's a great project i really love to work with this setup shout out so the way it works is that the tests which are actually inside these it closures [Music] are executed in isolation meaning that for each test all all the layers above are called independently so and the tests are actually um the names are concatenated so this test the full name is actually to do item uh underscore uh underscore underscore some underscores i will forget about the underscores so to do item altering check item changes completed so check item means i i i check it to be completed and on the right side here we have what we expect so we expect that the new completed value should be different to the original one but idea text and everything else should not change um and um so but yeah i want to so that's how this tests works but i actually want to point out how uh how we use this alter function here so it's just that we on the original to do item call alter and then we can hand over any change that we want to see reflected and it will return the new value um yeah and now we have um edits the forking um um so we can also inspect that um so spec it's it's not only a test it's a specs so you can inspect stuff so here for example we have a we can also see that the alter method can take a very very a a variable list of uh values it could also be invoked with uh with the array so now let's have a deeper look at the forking specs that have that are just applied so first we create a new original to work on we see that we can apply several changes at once and now we fork it uh with a with no changes and we expect it to have a different idea but the rest gonna stay the same so let's run the test as we have applied the git command as is the last git commit so we so we see that all tests have run successfully we actually have 176 tests so of course with all these small tests it's also very easy to to write a lot of tests and i mean many of this it's closes here you could copy and paste um well that's what i did so um yeah it's also great to to to have a lot of confidence in your tests and i also want to point out that [Music] you should not look at your test coverage so much but i want to point out that with this coding style it is easy to get a lot of test coverage very fast and i think that is a valid metric not the test coverage itself it doesn't matter it's well well it's it's not important that you have a very huge test coverage but it's very good if you can reach a huge test coverage very fast and with this architecture it's very very easy so let's go back to the to-do item implementation itself where is it so now that we have seen um forking in the test in action let's see the implementation so we have this alter function here if it's invoked with a fork change then we will actually immediately return the change item um and if it's not a fork then we will check if it's if there's a contents are the same because we actually don't want to to return the new item in that case um so and forking itself works like this that a new to-do item is created with a new uuid but with the self's text and other data points and if there are changes they are applied to this to-do item immediately by uh we are by calling auto on it so if the list is empty nothing will happen um but yeah this is pretty pretty much everything that we have to do uh uh outside uh that we have to do in the states the store will handle everything automatically so now we want to connect the user interface to it so what we need is that we need to have a frog message so our message is to do fork item with in the fork fork model so which describes this stuff as a model so [Music] we want to separate the message enums from all other dsls so we we could be tempted to just exchange the information that we have for forking at different places already but i introduce a model here because then we have a much clearer separation and it's also much easier to implement certain um uh certain protocols so this uh uh so this is the message that we have to uh to send to indicator forking now um we need to we need we need our to-do list feature to to react to this fork message so we do this down here and we call the use case the fork to do item use case request method with with a request [Music] with a request fork a fork item with with a list of changes and here again we have the full implementation with the interactor class again everything is a totally black box and uh if we request the interactor uh to uh to fork um uh it will actually do so in here um by altering um [Music] by altering the item and in this switch we translate the model that we have introduced the fork model uh to the appropriate dsl values and then we che uh then we change the store by adding uh the item to it and then the use case responds to its feature uh by informing it is that the item was forked indeed which actually means that we will end up in this place where the response is once again checked and now it's translated to a message that all the that's the user interface and all the features to understand and we also write a journal entry by triggering a message to do that but i won't walk you through that it works pretty much the same so um so now the only thing that is missing um is the user interface which ironically we already have implemented somehow because we in the user interface we do exactly the same as we do in the tests so that's why they are specs specifications um so let's already compile the new version of the app to make and look at the code at once the user interface is connected via a view state um it's uh it's for swift ui so it's it uses this observable object implementation it does nothing special it's yeah it processes any new state it receives and informs the user interface through this published items so let's look at the implementation so we have a list of um of to-do item cells here and the to-do item cell is implemented in this file and now the forking is implemented if yeah let's let's look at it so now our context menu also has a fork submenu and now we we want to remind ourselves for a week later that we want to buy beer but we want to buy be a urgently so first we give it another title and now uh [Music] now we change the due date we change the title or we fork with a new due date so pretty much as we would expect how does it look in code here we have the context menu if we want to change the date without forking the value of the item we do this so we say it's not forking and if we want to change the due date for a forked to-do item then we say yes it's it's forking and we want to present the date sheet as in the other uh way so the date sheet is then presented over here um and depending on if it's or not we send out to do fork item with the change or to do send the message to do change due to this other value for this certain item and we do very very similar uh for the text changes so with very little changes so let's yeah no i did not prepare that's it were really only a few lines of codes that we changed and pretty much only additive code um we created a new we created new value for the user because uh well they requested it now they can do it and it's been done yeah i mean i am not a swift ui expert so i i did i did have to figure it out but if i were a little more experienced since 50y i could have written this [Music] edition in the mia 10 or 15 20 minutes and and you will encounter a lot of use cases in this scope otherwise will be a little bit more effort but i do believe that um [Music] in in usual terms um use cases will require less than a day to be implemented yeah we have talked about the modelling state also the store um the funny thing about this store is that um although it acts a little bit like a class object it actually isn't neither a class nor restruct and i want to show you what it is so i decided to go uh also here a little bit uh out of the ordinary and um and i must say that after using this pattern in in three apps by now um i am very happy with it because it's it's it's it's just simple so what we see here is the declaration for the store usually you would go to a class for a store it's uh you need a reference type so stock wouldn't work and um yeah certainly a class would be the go-to type um but for the same reasons i didn't want to have a class in the central um of my architecture i also didn't want to use it for a store so i did came up with this construct star is a tuple of functions five functions being access change reset callback and destroy and um store is the composition of those functions um bind together in a tuple is this is this tuple or tuple i never know so how so this is just a declaration this is something we definitely need to implement so how would it look like here we have a create disk store function that implements this tuple for usage on a persistent store storing disk for example so um again we yeah so this um we have a this function that returns a store um the store is this tuple and in place we implement uh the functions we say well state just return state remember in in a single uh single statements function you don't need to use return anymore if you return so this function returns the state so it's like it's just the access of of the current state uh the change function applies uh changes that it it received by forwarding it to the state which is then written to this variable so this is this is the only place in in the app call where we need mutability so this declaration and this three statements for change reset and update are the only mutable statements in apps in my app core so in the features in the use cases and in in the state and model so yeah so it's very powerful yet if you get used to it it's also very simple well then it's persisted to store and so on um and the private implementations for uh for the top for the store persisting uh for for persisting the store destroying the store and loading the store are found down here so they are not accessible anywhere else so this is the only interface we have to create this store to create another store you could just implement another function and maybe have a co-data store [Music] if you notice closely i i said it it has to be a reference type um so that it can be passed around um yet if you if you do know a little bit more of swift you might be aware that the tuple is actually not a reference type it's a value type but that's actually the reason why we use a function on the top level here because they are reference types so um so when they are passed around it's still the same function um yeah so this maybe we should also talk shortly about this callback so callback is a function that takes another function as an input parameter and this is useful uh for this because this is now a very very simplistic notification pattern it's a listener pattern so that the store every time it gets updated will inform all its listeners so it's very simplistic we do not for even for such a pattern we do not necessarily need um classes so in this case we do not even need uh structs so yeah um again there is no underlying level uh underlying level here so everything is known to us we know everything we own everything of the implementation we we own our code with with with such a implementation while classes yeah yes yes they're difficult we've talked about it so as i said uh one reason why i started started thinking about uh doing things differently and try this route was that i wanted to have something that is easily usable in any kind of agile now agile as in process surroundings and environments and i want to show you this feature map which is a real project i've completed with this um architecture and i hope that this demonstrates that yeah let me explain you um so at the top we see user call chat these are the features in our app and in the next row we see the use cases and in the first column we see our sprints so it's a sprint planning tool and um in the area between those rows and um columns we see what i call actions here so mostly the user interactions with which we would trigger the use cases so now the idea is that usually a use case has one action sometimes two because sometimes you do the same thing from the different places in the user interface but usually um you have one action for one use case and the idea is that a use case is always so small that it can be done in one day um usually even much faster sometimes you will need more time than the day especially if you want to implement some some new algorithm but my proposal at this point is with this kind of architecture with agility built into the architecture you can actually ditch a lot of uh yeah um a lot a lot of the bow uh uh the bar rock baroque asked um stuff we have in our processes so the idea is if if a use case in average does not exceed one day you simply count the use cases and you can predict when you will be done so you count the use cases or the actions and the actions will be even implemented even faster because they are usually just one call in the user interface but they represent the use cases so yeah so the idea what i want to show you [Music] is that um the agility of the code flows back into our processes um yeah but i also guess you have to try it out so um let's see if i have missed some of those key facts yeah the app car is uh is is fixed or or static actually which means that once it's created at app time it doesn't change in any way it stays the same until the app is ended also model and state are immutable i've shown you that um so the idea is that if something cannot change it also cannot change unintentionally so there's a whole category of crashes and bugs that you cannot have in your code if you apply this kind of coding style and a customer once told me that he had asked [Music] a professional testing company to evaluate his uh his app and they replied that um and in the end report they pointed out that uh it might have been the first apps that they've tested that didn't show a single crash so yes yes immutability go for it really okay also i want to mention again um you should go for a uni-directional flow in your app it doesn't matter if you want to implement my architecture or another one you need directional flow always helps you to keep coding and under control because it becomes much more reasonable this also means forget about singleton please um i want to mention i have not demonstrated it but it was one of the first things i discovered with this uh architecture i want to mention that um the ui is swappable um you might want to do it for different reasons you want to maintain legend uh you want to support [Music] old devices with with a different ui you want to migrate um yeah or you want to actually implement different features because what i discovered is that it's quite easy to implement to use the same app core for different features example i've implemented an app call that just randomize spits out random stuff and i've created four different apps with it all all exact same app car but different uis and one app is a role game dice app one app does the same but on the command line so my command line so much more nerdy um but there's also a apple watch app that lets you flip coins or use an eight ball or whatever these things are called in case you are bad at decision making so the apps are very different but they use the same core um yeah i want to point out that that my architecture is something that i dare to call fractal because it is using the same pattern everywhere is the same module pattern which also results in very similar syntax as you can see the first line shows how to change her to do items the second how to add a to do item to an app state the third chain shows how to do the same thing but on a store and the fourth shows a call to add a to-do item as it would be sent from the ui [Music] yeah you have seen ui um with um a swift ui but uh ui kit is also quite easily implementable with some notifications um reach out for me if you want to have more calls on that yeah and you've seen the sample test and here i want to point out with this level of testing with this with this confidence we can build up confidence so the same the tests that you write for a to-do item are very similar to a test that you write for a use case or for a feature or even for the complete app call and so you can build with the same skill set you can build up from the model over the state and store to the use cases and features and app you can build up confidence which makes it yeah i just can say it feels like uh like like a little bit more like a mathematical proving uh to me than other unit testing you build up use you start you can start axioms the the models and from there you can build up your confidence to yeah prove like state yeah um this has been my uh presentation uh i know it's been a lot um and also have been the first time for me to talk to a monitor without any live audience i just have aquarium over there but they had been very mute no reaction from them so if you want to reach out to me you will find all the informations you need at this address you will find also my blog there i have a few articles there regarding this architecture also about immutable data types and [Music] swift you will see a some kind of journaling there which i didn't show here um yeah [Music] i hope a few people stay around with questions and remarks [Music] otherwise have a nice day and see you soon hey everybody and thanks for watching um yeah i don't know if there are any questions or maybe some suggestions on what we could talk now i definitely would like to to get some feedback on this and your thoughts so yeah so any remarks any comments would you guys could consider something like this to use in your projects okay about you are asking for the difference between spec and um and the tests and simply put there's none technical speeding there's no um difference um just that in this framework setting with quick and nimble um it's more like coming from the bdd style where tests are also meant to describe the system and what has been completed in the programming and something like that um to the product owner customer whatever yes exactly [Music] exactly any other question okay there are some things i had not the time to answer or to describe um mostly because i'm using too much ass as you can hear in my presentation um but i also want to point out that something that i did not really mentioned is that um this code also is pretty much completely declarative in opposition to being imperative what most codes in swift probably are today i have an article written about this that is focused on this aspect on the declarative part it's on medium it's called fully declarative swift for real world projects so uh if you would like to check it out it wouldn't make me very grateful um yeah and i would also be happy for any later feedback and if you want to get in touch with me do it wherever you can find me maybe on the slack server the yeah cocoa heads ml uh slack server yeah um yeah so yeah shall we end it [Music] [Music] [Music] so [Music] [Music] [Music] do [Music] [Music] [Music] [Music] [Music] [Music] [Music] [Music] [Music] [Music] [Music] [Music] [Music] [Music] foreign

Channel: CocoaHeadsNL

Views: 524

Keywords: CocoaHeadsNL, CocoaHeads, iOS

Id: l-WckUhhhII

Length: 107min 50sec (6470 seconds)

Published: Thu Apr 22 2021