Software design and architecture

Being RPO a book I really loved and enjoyed from the very first time I read it, I think we can rescue one or two things besides the entertained story and the wholesome references. I hope that those who read the book can see them and think at least a little about those topics. In the book, we have this society that has seek refugee of the reality inside a virtual world called Oasis, because for them, reality was not as interesting, or in some cases reality was really a terrible place to be. There is also this world with almost all the resources wasted and in consequence a lot of people living either in an extreme poverty, or being miserable with the little income they had, which pushed them further into Oasis.   Our reality being not as bad as this world inside R.P.O. nowadays this imaginary situation where people aisle themselves is similar to what we tend to do with technology and social media. We tend to create this image we want other people to see on this media and we car

During my first years studying programming, I always considered that creating a program that wrote programs was something quite confusing and complicated. I consider this article to be something useful and simple to introduce the concept of metaprogramming, even if I got lost at some point of the way and did not completely grasp the whole idea. The professor is right in that a metaprogram is usually considered as something complicated and a little bit mystified. It was quite helpful that the example for the introduction to this topic was given in ruby, since it is a very simple yet powerful language that is dynamic and lets you concentrate in the concept rather than in the language syntax, almost like it was pseudocode. What was left not so clear to me is how code modification during runtime can be considered as metaprogramming. Since it is something so exclusive of certain languages and until this course I had not been introduced to it or used it, I’m not very familiar with

It is not the first time I have heard of Microservices, but I never had the time to really get into the subject. In particular, I believe that the Monolithic helps to visualize the reason of why microservices have been a hit, rebuilding and relaunching a whole application each time something changes. It may not seem something crazy… if we are talking about a small app, but when you really think about it in the real and productive world this can be quite difficult and that’s when microservices come in to save the day. The main advantage of a microservice style is that it makes everything modular, so you don’t have to go through the process of deploying the whole system with every change that is made, but it is not the only one. It also allows you to create several small cross functional teams, and what really caught my attention is the view that this style has over software and products, not just over projects. It makes more sense to me to think about software as a product that ev

When working on a software project, if you do not have a guide and keep in mind the whole picture, sometimes you as an individual that is part of a team, tend to forget about everything else but the part that was assigned to you. That is what the blog of this week is about and what a perfect example was the elephant story. From a personal perspective, I can say that this is a reality. If not as dramatic as the elephant chaos created by the blind people who failed to get the whole picture, it was quite funny to say the least to face this situation. Our last semester while working in the intelligent system, the front and back teams ran into a difference about the format of the data that had to be passed between applications. This happened because when each team started to work on their part, encapsulated in their task and never reached out to the other team to reach an agreement and in the end even the data mining and the AI teams got involved. This type of situations tends to

Although the SOLID principles are something that should be, at least, common in object-oriented programs, we programmers tend to forget about some of them and incur in practices that negatively affect our code. From the beginning when we are taught OOP, we might not be aware of these principles even if we tend to gravitate towards some of them depending on how we learn to OOP program. For a start, I think that when we learn to program in the Object-Oriented Mode, we usually are taught to apply Single Responsibility because it is easier to think about classes as a description of an object that has a set of characteristics and one function. It might cost a little at the beginning to effectively accomplish this, but when you gain some practice, for the sake of clarity this is usually the go-to way. The next most usual behavior I follow is the Interface Segregation Principle. Since it is somewhat similar to the Single Responsibility, it is easier to understand and then apply in t