S/W Design and Arquitecture

After having read Ready Player One by Ernest Cline, I want to talk about the next two quotes: Morrow wrote in his autobiography that he’d left GSS because ... he felt that the OASIS had evolved into something horrible. “It had become a self-imposed prison for humanity,” he wrote. “A pleasant place for the world to hide from its problems while human civilization slowly collapses, primarily due to neglect.” (p. 120) and (Halliday speaking) “I created the OASIS because I never felt at home in the real world. I didn’t know how to connect with people there. I was afraid, for all of my life. Right up until I knew it was ending. That was when I realized, as terrifying and painful as reality can be, it’s also the only place where you can find true happiness. Because reality is real.” (p. 364) These quotes are so captivating and I agree with both of them. If we think about nowadays (October 30, 2017), our OASIS is each one of the places where people try to escape from reality,

Using microservices is one of my favorite things on projects, they make it easier to reuse already done software written on any programming language. The only drawback is the complexity of organizing those microservices. Another problem is to define how small your microservice should be. This microservice can scale horizontally by running many instances behind a load-balancer. As Martin Fowler and James Lewis said, a microservice has the next characteristics: Componentization via Services Organized around Business Capabilities Products not Projects Smart endpoints and dumb pipes Decentralized Governance Decentralized Data Management Infrastructure Automation Design for failure Evolutionary Design For me, the best implementation of microservices are APIs and packages that can be called in order to create or transform a piece of information with certain operations/instructions. Now a days we don't create a server entirely, we use a package to create an endpoint that ca

UML everywhere, or that is what every professor at my university has taught me. In addition there are other ways of viewing the software architecture. 4 + 1 View is one of this ways, 4 + 1? Yes! isn't that 5? Well this is because the called "5th View" are the scenarios. View Name Logical View Development View Process View Physical View Scenarios Description What components are going to be made and how they will behave What belongs to what during the development Concurrency and synchronized stuff SW (Software) and HW (Hardware) relations AND the how the system looks when finished Interactions between the components Diag

The SOLID principles are great to reduce the possibility of things going wrong, but how can they do it? Well as the reading says, by minimizing class dependencies. These principles are: S ingle Responsibility Principle  O pen/Closed Principle  L iskov Substitution Principle  I nterface Segregation Principle  D ependency Inversion Principle A great example of the Single Responsibility Principle is the usage of microservices. This services have a main purpose and most of the time they only work for that. For example an OCR (Optical Character Recognition) microservice should only accept an input, try to recognize the text inside the image and return a result, nothing less, nothing more. Any variation should be coded outside the microservice to have a different result. An image that can help you understand it is the next one: For the Open/Closed Principle I think that a good example is the ToString in which you only change the "behavior" of the class you are

The podcast about Software Craftsmanship in which Robert Martin talks was entertaining, it was recorded in 2009 and it makes sense now a days (2017). It was interesting how it talked about the manifesto and the tools that every programmer should get used to.  Talking about the manifesto, I'm always thinking on the outcomes that could bring every change in any program that is being coded. Thinking that everything can be molded fast is a wrong idea that most people don't get. They want new features and they want them now. Not taking the time to make unit tests and just ship it will doom a project because it will start to diverge and start changing in ways that will make it really difficult to solve if a bug arises or a new feature is asked.  And now, talking about the tools, I at least thought about learning how to use a terminal and a text editor as Sublime Text, Visual Studio, Atom first. The IDE makes it so magical that sometimes a programmer doesn't know what to

In every coding project there are people that will write it and some others will design it but without any question, both of them should know that coding isn't trivial, design errors or coding errors will occur and it is essential to have a risk plan in case that something happens. This allows to have a stablished way of dealing with the problems that will appear as the project grows. Depending on the scope of the coding project, if it will be a program that has some components (an API, a database, users, security, etc.), it is important to design it before beginning to code it. This allows to design it to be scalable, secure, maintainable, and error-prove. If the project is just to write a a program that will resemble a calculator, it is just fine to code it as you go. This means that depending on the complexity of the project, it is necessary to define certain documents to establish the foundations that will allow to create bigger projects (more modules, more people assigned t