Ready Player One

We currently live in an age where technology is slowly taking possession of our homes. Something that I seem really sad is to see families reunited, and that each member is looking at his cell without setting any conversation. I dare say that technology improved the communication but, got worse quality.

I do not consider that evade the reality is a good choice, sooner or later we have to face our problems and doing so gives us maturity and growth as a human beings. I know that many people use this kind of thing because it helps them get ahead, for example, of a strong depression, but in my opinion I think that for everything there is a balance to avoid falling in excesses.

We can compare Oasis with the social network Facebook, for example many people publish a lot of nonsense things, or worse even, making public everything that they do (to where they leave, what they are eating, what bought, etc.) without seize the opportunity to enjoy their activities. Now the problem is that many people hide behind a computer and displayed through it as something they're not or worse even, looking for acceptance of people through likes.

It's interesting how most futuristic novels narrate a world desolate, where everything is dead and there is no hope for humans. I do not know if this is a coincidence, or if indeed we are leading the world to a similar situation, from my point of view I think we are not far away from becoming in a society like that show us some books.

Of course it is possible to have a world like Oasis, augmented reality is something in which many experts are working, and the technology is progressing ever more quickly, so we should not doubt that in the future we will have access to our own Oasis.

War Games

This movie seemed to me so impressive, firstly as a child can have as many skills being so small. Secondly what could have caused this child to use their skills.

At first it may sound funny the issue of that one boy has confused a program of a military station with a video game (given the violence in video games, any other would have confused too), but once you thought about the damage that he may cause , the situation leaves to be so funny.

What I learned from this movie is that you have to protect things that are important for you and are within your computer, as you never know who could prowl around. Of course that we do not have programs to launch nuclear bombs or something like that, but I imagine that if someone hates me, can get into my computer and erase my final class project Software Architecture. Of course my teacher would not believe me, and would jeopardize my grade.

Retaking the matter, I believe that security is something we can not put aside. Those who are taking the computer forensics topic, we can get an idea of the information that we can access within a computer.

Although the film is somewhat old, I allowed myself to make a comparison with children of this age. I sincerely believe that children of today have great potential to exploit, but the problem is that this potential is misdirected. If schools put more emphasis on quality education where children have access to other activities that help them at channeling that knowledge, we would have a very promising future.

Taking what happened on the positive side, was good that the attacker was a child and thanks to this, the military could find vulnerabilities in your system that they not believed have. If it had been a terrorist they would not have had the same opportunity.

Microservices

This article deals with the subject Microservice, which is to separate a program into small services where each of them running in their own process, I remembered the motto of a sorting algorithm "Divide and conquer" whose objective was the same. The purpose of this style is facilitate the updating and modification of our program. It is mentioned that in a monolithic programming style, you can't change a single module, needs to be updated whole the application or program every time a change is made.

On the other hand in a style based on Microservice we have the advantage that if we modify some modules of the application, we can go only to the module or service that will be updated and this is enough for the changes to be reflected the whole application.

Another advantage of this technique is that by putting each element as a separate service, in the situation where a replication of data related to the information stored in the database is required, only the data replication that is required are performed and not all the information as would be done in any other style. This allows to carry out this task effectively and without wasting resources.

Componentization (term ascribed to the action separating an application into services) has as main advantages:

•  Allows services are independently deployable, so modification is simple and effective.
• Minimize cohesion, which refers to the relationship maintained with other services and that both affect the changes made in one service to another service.

The industry related with information technology (IT) chooses to organize services depending on your skills or capabilities, this allows a group to be able to develop and operate the same product, and not as has been done in recent years, that people who develop applications are not responsible for the maintenance of it.

The 4+1 View Model

Personally this blog activity I really liked, both videos and the reading, I found them very interesting and applicable to everyday life and, in our case to our coding methodologies.

In the first video we can observe how UML diagrams play important roles in each stage of software development . Each stage has a purpose, but we must not forget that each relate to each other and at the end the greatest relationship that they have is with the UML diagrams. The comparison with respect to the planes which a builder performs before a building is built, it is very accurate because as has been mentioned on many occasions, are the foundation of our program.

Moreover, what most caught my attention was the second video and the reading. Each of us has a different perspective on things, this depends precisely on how we observe things or attention that we put in some details. Relating this to programming practices, sometimes maybe we do not realize of certain aspects or details of a program, but someone else makes us see another perspective or, sometimes each person understands a different thing, but in the end you get the same result .

Another important aspect is the relationship of an all in a set or object. I think a very important weapon are groups of working where, before developing a project are presented to developers the necessary requirements, and once they are analyzed, each of the people involved gives ideas according to their view about the things. I think these practices also help create more powerful programs and it contribute to sharing knowledge, and gives us the opportunity to learn new things, we must not closing ourselves off  to our ideas. A person who does not open to new thoughts is like a blind man who clings to what is touching, its what he thinks or believes it is.

Understanding the SOLID Principles

The article of this week emphasizes again how to improve our code, to make it more efficient, ease maintenance and reuse it. Five principles are mentioned, which we should follow to improve our practices when developing code. These five principles were first identified by Robert "Uncle Bob" Martin, but the acronym SOLID (by the initials of each principle) was introduced later by Michael Feathers.

Each of these principles establish certain rules to follow, below they mention each of them with its brief explanation.

1. Single Responsability Principle

It states that you must give only simple responsibilities to the classes, thus avoiding dependence between them. It also specifies that can be assigned to a class the responsibility of a group of classes, all to facilitate future modification of code without affecting the other classes.

2. Open/Closed Principle

It states that classes should be open for extension, but closed for modification. It is recommended to control the behavior of each of the classes through inheritance. The main objective is to avoid making modifications to classes, it is better to have an extension that controls everything and make the change directly on it.

3. Liskov Substituiton Principle

This principle is similar to the previous, except that it focuses on maintaining a good relationship between classes and functions. Also recommended not to make changes in base classes.

4. Interface Segregation Principle

It states that we should avoid writing large interfaces. To improve recommends creating collections that contain these interfaces discreetly and smaller, through dividing into groups depending on what interfaces do.

5. Dependency Inversion Principle

The last principle states specifically, avoid dependence. It recommended interfaces to carry out the relationship between the classes that we want to have relationship.

Each of these principles are aimed at improving practices writing code and ease of maintenance, modification and reuse it.

Software Craftsmanship with Bob Martin

The metaphor used by Bob Martin saying that software development should be craftsmanship, I seem very accurate because, craftsmanship is any product that is made with art and technique usually performed with hands and with good quality. This is exactly what Bob tries to explain, how we can create a better quality software and do not  make programs only for do, without any sense,  and without paying attention to the quality of the final work.

Bob's idea to create a change in people is good, but complicated. Usually, as programmers, we are used (not all, I'm not generalizing) deliver programs for the sake of fulfilling a contract and  only by that reason. We do not consider the quality of the code, most of the time we do not even take into account if we solve the problem in the most efficient way,  just care about giving the solution.

I consider that every work we do speak a little of ourselves, therefore we should pay a little more interest to do so. If we really love what we do, we must try to do our best effort. Perhaps the same IT industry lead us astray, to make us believe that a quickly software outsells than a good software, but I think we need to change this belief. I do not believe some company prefer something quick but that in the future will give them problems that could represent extra expenses for them.

We can try to change our mentality, not only to develop programs but also in other things. We must see the software as a craftsmanship that we create, and the documentation like your support. Sometimes the program may be clear to us but not to others, and therefore the explanation never hurts to. Besides this good practice can occasionally save our life in an emergency code.

Is Design Dead?

This article stands out again the importance of design in programming. I found it very accurate the part where mentioned that people focused on programming underestimate the work of the dedicated to the design, without considering that both techniques are combined to achieve the best of a program.

An important concept is refactoring as it can sometimes be useful, depending on how it is used. For example, we must not believe that refactoring corrects errors that were committed in the past because it is not. In addition, you should keep in mind that this technique will only work in a proper way if you have a good design. People are inclined to use UML diagrams for design, others simply do not, the only important thing here is that the design should be as simple as possible.

Again the software architecture and the importance of knowing different design patterns to improve the programs is mentioned in a matter of simplicity. It is mentioned that the programs should be simple and able to be understood by people who maybe not engaged in coding.

A point to be considered is that the design is an aid to deployment part, and with aid I want to say that could prevent errors. It is recommended that if you are in that part of encoding and errors that could belong to the design are found, they must be corrected and documented in the design, which does not always take place.

As programmers, and so that our programs have a longer duration, we should not leave aside the design, since as we have been learning in other articles, is an essential part of a program that not only improves the quality, also help saving time and money in a big project, and a good design can get us out of many future problems.