S/W Design and Arch Nat's Blog

The microservices architecture is a recent term used for this new perspective for the software architecture, and it's based on getting several small services running into a single application that are communicating constantly with the computer via API using HTTP. This information may appear a little so technical but will get relevant at the time of understanding it's structure and purpose. It may appear that is not that different for the traditional model of architectures like the libraries but the microservices get you benefits like the independence of the services, every service could be used and saving a lot of processing for each application opened. This independence also helps at the moment of creating efficient interfaces and to get explicitly the function of every service. The changes in organization, and the approach changing from a project model to a product model, are also differentiators that makes interesting changes for the microservices perspecti

For this week we have several material to use, and I found it great. First the video that gets us the theory for the 4 different perspective model architecture plus 1, this part of the homework is connected to video that told us a story about the blind men who touched an elephant, and this two are necessary for fully understand the last article, getting combined into this new story about the programmers that found a new program thing and get to understand it in different ways. Its important to mention first the 4+1 model and each view of it, getting initialy the logical view explaining the behavior of components using state machine or sequence diagrams, the process view that gets the way of communication for the different system processes, also we got the development view that describes the elements and the components for the system in order to be completed, at last for the fourth view we got the physical view giving us the physical distribution for the components as well as the topo

The first interesting topic I find here is focused for the object-oriented programming, but even with that this in mind, we find it useful for other purposes. This might appear a little out of place, but the distinction here is necessary, because I've felt that some concepts are strongly related to the OOP. Anyways, we have here five solid principles for design and getting the code more intuitive and to avoid the most dependencies that we can. The first principle is the "Single responsibility" one and the name is very explicit, it's for getting each class doing one and just one thing, this I see that applies for the methods too, getting in the example some problems for a method that does more than one task. I would ad to this that the name would explicitly say what does each method do, because this is also a problem clearly presented. The second principle is called "Open/Closed principle" and refers to get the classes/functions to be open to the extensio

I've never seen this movie before, and I had a great surprise, even when I did saw the "remake" form 2007 and I consider it as a meh movie, I really enjoyed this one. First of all, I was hooked at the star because of the protagonist, that is not sold to us as an unreachable super genius of the computers, but as a geeky guy that had plenty of free time, and the incorrect decision making on his childhood. Adding to this, it feels like a character that happens to be in the middle of extraordinary events, using his own skills to get out well from the chaos that is made by he trying to find the new video games form an interesting company. The plot is interesting, as my professor said, for anyone in the last decade to get interested into computer systems or programming careers and get me with the doubts if I had real expectations around when I got into computer systems engineering or I was actually expecting some kind of super hacking courses and to being sit in

I liked this podcast, it has some strong opinions from Bob Martin that even considering that the podcast is from 10 years ago, are really applicable for the industry of the software. I think that programming is very satisfying just for some of the reasons that are described as the craftsmanship, like the art that involves maintaining the readability and the refactoring always clear into the code, and not getting totally disconnected from the design even when into the Bob's preferences around the agile methodologies. One of the points that got my attention is the way he expresses himself about the design and architecture documents (and other documents as well) letting us know that the agile methodologies can produce outputs of any kind, that this mentality as programmers of not producing any kind of documents while working agile it's just wrong, and we shall just be used to get great practices into our own process of making software. Other topic that it's touch is this i

For this article there is several topics that appeared very interesting to me. For the initial themes treated, one was the difference between the traditional structured design, and the evolutionary design, and it's a matter that I've even seen as a difficult topic because of the different perspectives presented even by my own teachers, some of them teaching me that the planned design is extremely important and even forcing this practices into our projects, but in the other perspective, some professors taught me to be evolutionary, and to make incremental design based on prototypes making really confusing the decision for the design every project I've made. Also, one of the things that I've found curious into the article is the association that the author makes between the refactoring and the YAGNI's simplicity to the evolutionary design. It's not that usual to understand the "best practices" of programming as supporting any bigger concept than the co