Hello, today I will talk about the use of microservices in software design.
Microservices are defined as an application that uses components where a main controller connects different web services that could be programmed in different programming languages and use different data structures, it is the ultimate application of the "Divide and conquer" strategy. Where programmers develop a service and connect with the people that use it.
A great benefit of microservices is code reuse by using a service in different applications, in that way, application developers focus on more important tasks by utilizing components as libraries, another benefit is that an enterprise could have specialized teams focusing purely on web services, front end or back end programming, everyone using other teams projects as components.
The hard part comes when trying to communicate with different processes, microservices need to be easy to use, well documented or any project using a specific microservice could crash each time it gets updated, another problem is that microservices are usually more expensive to use than native methods, so if an application performance is a critical aspect, microservices could be a bad choice (it all comes to terms on choosing the best trade-off in the end.
The last critical aspect I would like to talk about is that microservices should be well programmed, since many applications may depend on any microservice, it should be almost perfect, since a failure could cause a lot of problems on many applications, the risk of using a bad microservices is greater than using a bad method on a native application.
Microservices are much like any new programming language, developers either love it or hate it, however, in today's 'build it as fast as you can' programming enviroments microservices offer a lot of flexibility to programming projects, and as any new technique the hard part comes when a project manager has to choose the trade-off thats works best for a project on a specific context.
Wololo.
miércoles, 30 de marzo de 2016
miércoles, 16 de marzo de 2016
The 4+1 View Model
After two weeks since my last entry today I'm going to talk about the 4+1 view model.
This blog's song will be "I'm Comin Back" (That's the actual title) by Balance and the Traveling Sounds, great mix of funk, hip-hop, enjoy.
Software can be seen from different perspectives, each of this perspectives usually specifies on one aspect of software, a programmer may see a software project as a bunch of components built together, another programmer may see the same software project as many process working together and calling other processes, a more hardcore programmer may see the same software project as a bunch of bits being carried around between secondary storage and the processor, those bits being manipulated on each step of the process (I'm talking about some hardcore assembly programmer). A Lisp programmer may see the same program as data being processed in lists. Then a Lua programmer would not see anything, as he'll be eating glue and crayons (that would be me).
The elephant and the blind men story relates one of the main problems in software development, there is many ways to see the same thing, and all of them are right in some way, but everyone is wrong when used alone. Software programs are complex systems, made up of many components, working together to acomplish something, a software architect may need to have the skills to define the combination of representations of the same thing to get the best idea of it.
The 4+1 view model is one way to approach that problem. It defines 4 main perspectives and 1 that summarizes every one of them, focusing on the easiest way to explain software to a non programming human (yes, I've come up a term for that), in fact, I'm a strong believer that humanity can be expressed as 10 types of humans, those who understand why 10, and those who actually think of the number 10. Those who binary, and those who don''t.
Putting bad jokes aside, let me discuss the 4+1 view models below.
Logical view: The blueprint for project managers, a view that explains from a high level the components of the system for someone who has to understand from high ground what the slaves are doing below. In Egyptian sphynx this blueprint would have something like definitions for (Arm, leg, hip, sphynx head, etc.).
Development view: The blueprint for programmers, the working hands of software development, the slaves putting together the bricks for each sphinx's leg. (Not being serious).
It is a lower level diagram for the people that work in specific subcomponents of the system.
Process view: The blueprint for explaining when two components will communicate. In software, this view explains mostly concurrency, server-client interactions. In my egyptian sphinx example, it will explain how the sphinx communicates with other pyramids on Egypt that are aligned with the mayan pyramids to communicate with the aliens that humanity has already invented seedless watermelons and the end is near.
Physical view: This blueprint explains how software will deploy on a physical device. In software it mosly explains the system on which the software will be installed, on my now weirder egyptian sphinx example it explains how the telepathic module was installed on the top of the pyramids and the sphinx's head.
The +1 view, use cases: I actually love to use use cases, they are a simple, effective way to explain someone who doesn't have to know implementation details how the system will work (usually that is the client).
A pretty good thing is that use cases don't deal with implementation details or the subcomponents, they just define the behaviour and the actors of the system.
Use cases are much like approaching to a girl in a bar and telling her "I have a 3-step life plan, the first step is approaching to you, the third step is being married and throwing crazy parties on our house in Dubai." and when she asks "What is the second step?" you smile and answer "that's the part where you make a choice, would you like a drink?" (As odd as it may sound, it actually works).
In this analogy you hide all the implementation details of your plan (even the fact that you don't really have a plan). You just refer to the expected behaviour and actors of the system.
Perks of studying software architecture.
That is all for now my fellow reader(s).
Wololo.
This blog's song will be "I'm Comin Back" (That's the actual title) by Balance and the Traveling Sounds, great mix of funk, hip-hop, enjoy.
Software can be seen from different perspectives, each of this perspectives usually specifies on one aspect of software, a programmer may see a software project as a bunch of components built together, another programmer may see the same software project as many process working together and calling other processes, a more hardcore programmer may see the same software project as a bunch of bits being carried around between secondary storage and the processor, those bits being manipulated on each step of the process (I'm talking about some hardcore assembly programmer). A Lisp programmer may see the same program as data being processed in lists. Then a Lua programmer would not see anything, as he'll be eating glue and crayons (that would be me).
The elephant and the blind men story relates one of the main problems in software development, there is many ways to see the same thing, and all of them are right in some way, but everyone is wrong when used alone. Software programs are complex systems, made up of many components, working together to acomplish something, a software architect may need to have the skills to define the combination of representations of the same thing to get the best idea of it.
The 4+1 view model is one way to approach that problem. It defines 4 main perspectives and 1 that summarizes every one of them, focusing on the easiest way to explain software to a non programming human (yes, I've come up a term for that), in fact, I'm a strong believer that humanity can be expressed as 10 types of humans, those who understand why 10, and those who actually think of the number 10. Those who binary, and those who don''t.
Putting bad jokes aside, let me discuss the 4+1 view models below.
Logical view: The blueprint for project managers, a view that explains from a high level the components of the system for someone who has to understand from high ground what the slaves are doing below. In Egyptian sphynx this blueprint would have something like definitions for (Arm, leg, hip, sphynx head, etc.).
Development view: The blueprint for programmers, the working hands of software development, the slaves putting together the bricks for each sphinx's leg. (Not being serious).
It is a lower level diagram for the people that work in specific subcomponents of the system.
Process view: The blueprint for explaining when two components will communicate. In software, this view explains mostly concurrency, server-client interactions. In my egyptian sphinx example, it will explain how the sphinx communicates with other pyramids on Egypt that are aligned with the mayan pyramids to communicate with the aliens that humanity has already invented seedless watermelons and the end is near.
Physical view: This blueprint explains how software will deploy on a physical device. In software it mosly explains the system on which the software will be installed, on my now weirder egyptian sphinx example it explains how the telepathic module was installed on the top of the pyramids and the sphinx's head.
The +1 view, use cases: I actually love to use use cases, they are a simple, effective way to explain someone who doesn't have to know implementation details how the system will work (usually that is the client).
A pretty good thing is that use cases don't deal with implementation details or the subcomponents, they just define the behaviour and the actors of the system.
Use cases are much like approaching to a girl in a bar and telling her "I have a 3-step life plan, the first step is approaching to you, the third step is being married and throwing crazy parties on our house in Dubai." and when she asks "What is the second step?" you smile and answer "that's the part where you make a choice, would you like a drink?" (As odd as it may sound, it actually works).
In this analogy you hide all the implementation details of your plan (even the fact that you don't really have a plan). You just refer to the expected behaviour and actors of the system.
Perks of studying software architecture.
That is all for now my fellow reader(s).
Wololo.
martes, 1 de marzo de 2016
The SOLID principles
Today I will talk about the SOLID principles and the article "Understanding the SOLID principles" by the book“Ace the Programming Interview: 160 Questions and Answers for Success”.
The song of today's blog will be "Across the overspass" by "The Solids".
The SOLID principles talk mostly about how to do clean code in object oriented programming.
"S" stands for "single responsability", which means that classes should have the logic to handle a specific task or set of tasks, it can be summarized as "if class A handles A and B, you should delegate B to a class B". The reason for this is simple, if you have to modify something related to activity A, it is great to open class A and see only the code that handles it.
"O" stands for open/closed principle, which means that classes should be designed in a way that they can be extended, but not modified. The reason behind this is that if you have to modify a class, you will most likely have problems on other classes that use the class. If you need to add some functionality to the class add it, but don't try to fix something that isn't broken, or you'll end up redesigning the whole house just because you needed to add a lamp.
"L" stands for "Liskov sustitution", which basically means that if class B and class C inherit from class A, the methods for class B and class C should be interchangeable, that of course limits the power of inheritance, but also brings peace between child classes, if a class should implement some funky chunk of code, it is always better that it gets it by composition rather tan inheritance, or trust me, things will become messy.
"I" stands for "Interface segregation" which is sort of a variation of "S" applied to interfaces, it basically means that instead of having an interface for a big chunk of logic, you apply "divide and conquer" and make every interface define a specific behaviour, and let classes choose to implement the number of interfaces that handle the logic each class needs. Sounds simple.
"D" stands for... "Dependency inversion" (what else did you think?) which means that code should have minimal dependency, so instead of having a class A that has an object of class B that has a set of behaviours you define an interface B and a class B and BAlternative, then, on class A you can just define a method that calls the logic of Interface B (which can come from class B or class BAlternative). That way, the behaviour of class A and class B isn't coupled.
Object oriented programming is extremely powerful for some programming problems, however, it has to follow design principles to void messy code, a problem on object oriented programming is that if you do not design well your solution, everything depends on everything, and a minor bug on class A can cause the whole thing to crash, then becoming the debugger's nightmare (where each time you clean a bug you uncover other 10 bugs on other classes, recursively, until you get a debuggerOverflow exception and everything goes bad).
Thats all for now, wololo.
The song of today's blog will be "Across the overspass" by "The Solids".
The SOLID principles talk mostly about how to do clean code in object oriented programming.
"S" stands for "single responsability", which means that classes should have the logic to handle a specific task or set of tasks, it can be summarized as "if class A handles A and B, you should delegate B to a class B". The reason for this is simple, if you have to modify something related to activity A, it is great to open class A and see only the code that handles it.
"O" stands for open/closed principle, which means that classes should be designed in a way that they can be extended, but not modified. The reason behind this is that if you have to modify a class, you will most likely have problems on other classes that use the class. If you need to add some functionality to the class add it, but don't try to fix something that isn't broken, or you'll end up redesigning the whole house just because you needed to add a lamp.
"L" stands for "Liskov sustitution", which basically means that if class B and class C inherit from class A, the methods for class B and class C should be interchangeable, that of course limits the power of inheritance, but also brings peace between child classes, if a class should implement some funky chunk of code, it is always better that it gets it by composition rather tan inheritance, or trust me, things will become messy.
"I" stands for "Interface segregation" which is sort of a variation of "S" applied to interfaces, it basically means that instead of having an interface for a big chunk of logic, you apply "divide and conquer" and make every interface define a specific behaviour, and let classes choose to implement the number of interfaces that handle the logic each class needs. Sounds simple.
"D" stands for... "Dependency inversion" (what else did you think?) which means that code should have minimal dependency, so instead of having a class A that has an object of class B that has a set of behaviours you define an interface B and a class B and BAlternative, then, on class A you can just define a method that calls the logic of Interface B (which can come from class B or class BAlternative). That way, the behaviour of class A and class B isn't coupled.
Object oriented programming is extremely powerful for some programming problems, however, it has to follow design principles to void messy code, a problem on object oriented programming is that if you do not design well your solution, everything depends on everything, and a minor bug on class A can cause the whole thing to crash, then becoming the debugger's nightmare (where each time you clean a bug you uncover other 10 bugs on other classes, recursively, until you get a debuggerOverflow exception and everything goes bad).
Thats all for now, wololo.
Suscribirse a:
Entradas (Atom)