S/W Design and Architecture

The article is about the “SOLID principles”, which are five important principles of object-oriented programming and design and which recurring theme is the dependency’s avoidance, these are: Single Responsibility Principle: this statement says that a class should have just one responsibility, and that it might be just changed if there’s exactly one reason Open/Closed Principle: here we talk about that a class or function should be open for extension but closed for modification Liskov Substitution Principle: ability to work with a child class inside a function that is expecting the base class Interface Segregation Principle: avoid writing giant interfaces that classes may not need or want Dependency Inversion Principle: instead of writing code that refers to actual classes, better write code that refers to interfaces or abstract classes These practices are interesting as the refactoring or pattern practices, the reason makes sense after you read the description ...

The movie is funny and attractive, at the beginning I was not expecting anything from the film, in fact I though the subject was going to be different from what I imagined when I read the reference in Ready Player One. The plot is amazing but dumb, maybe it was true, I do not know but the going of a kid being able to hack a super sophisticated army computer and initialize the World War 3 prelude is as I said amazing but realy dumb. In other hand the other part of the movie, the militars and scientists from the base are again, dumb, the lack of mechanisms and plans to aboard a situation like the one presented in the movie is surpressingly worrying, the whole movie is supported with this premise, the lack of capacity of the staff of the base to deal with the idea of ​​someone being capable to hack their super sophistifies device so easily and their incapacity to detect and stop the computer malfunctioning As an engineering I think the movie touch important subjects of our area, ...

Robert C. Martin (also known as Uncle Bob) is a software engineer and an author of multiple books, in this podcast talk about software architecture, craftmanship and agile development methodology. The talk begins with Robert telling us how his experience as a software architect was and explaining that he thinks that there’s a bad practice at the industry. He thinks that drawing a line that divides the architect and de developers makes no sense, because the architects are the major participants at making code decisions but usually, they’re not well involved in the coding process, they are not familiarized. In other hand, Robert talks about “software craftmanship”, this idea defines that a coder needs a real knowledge about coding, and this knowledge needs to be “learned” with the help of a teacher. Something like the “pairs programming”, this means that to really learn to program we need to watch and help another person programming. This idea has four statements (manifesto): N...

The article unify the previous topics of the articles we've readed, also I can notice a relation with other topics I'm taking in other classes. The three principal axis of the article are refactoring, use of patterns and "code and fix vs. planned design". The relationship between the first two topics with the third one is the way to use them combined with an agile development methodology. The article also specifies the advantages and disavantages of the methodologies. The whole article tries to decide if the advantages of the agile methodologies have already overpased the advantages of the classic ones. The author explains that the work throught an agile methodology should contemplate to refactor the code. That this practice is good to make more easier to read and use the code, because refactoring can help us to know if the code has no duplication, helps reveal the intention and know if we have the fewer number of classes or methods as possible,etc. The beniefits...

The author really "takes a stab" as he said trying to define "architecture" and "architect". He define these words as a way to make "desing" and "designer" sound important. As I said at the previous blog entry, the blueprints in the software context are a tool used to describe at a high-level way, the software model. This article, complets this description, explaining that the software's architecture is the organizattion of the principal and more important components, and how they interact and the smaller pieces that compose them. Later, the article do an unexpected "plot twist", arguing that this description fall in a technicism area, because the "high-level" decription is just useful for the expert developers that are familiarized with TI concepts.  The abstraction of the most important components is unprecise becuse these components importance is defined by the architect. Something that is true, because t...