Ready Player One

This week blog, is going to be a reflexion of the book "Ready Player One" by Ernest Cline. The following two paragraphs are going to be used as the starting point of this reflexion.

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)

(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)

In order to make a more accurate reflexion, the following questions are going to help to achieve that.

Do you agree with the two previous quotations?

Yes, I believe virtual worlds in general are a way to escape reality. It is easy to interact with people you don't actually see, if you have a problem with someone you just blocked it. The real world is far a more dangerous this, you can't undo things, but everything in the real world is "For REAL" you are going to have it and you are going to feel it, so it's define worth the risk.

Do you personally see any virtues in a system like the OASIS?

Of course, “OASIS does tons of good for people,” the techie protested. “Their schools are the best primary educational system in the world, and they’re free.“ (Lacero, Andy Weir) You can meet people from all over the world and learn a lot of new thing, languages, customs, songs, literature, etc.

Do you think our value system (personal and cultural values) could be altered if we spent most of our time in an OASIS like system?

Definitely, I believe people turns cold in social networks, it's easier to be rude, and it's easier to say what you think without having any consequences. 

Do you think that there are any similarities between the OASIS and the way we currently use IT technology (computers, game consoles, smart phones, etc.) and social networks (Facebook, Twitter, Instagram, Pinterest, etc.)?

Yes, but not at the same level, I might even say that in OASIS you hace a change to learn something, and these social networks are used mostly for gossip and entertain. We (human race) are easily absorbed by this because we want to escape from reality, we want to live in our fantasies and that can lead to awful accidents.

Did you find any interesting resemblances between the dystopic “real world” presented in “Ready Player One” and those presented in other works of fiction such as “Nineteen Eighty-Four”, “The Hunger Games”, “The Matrix”, “Soylent Green”, etc.

Sure, it's a little bit frightening that most authors see the future the same way, the riches way up in an private space and the poor fighting to survive, to live with a lot of people in the same space between garbage. I hope we don't get to that.

Do you think it’s possible, technologically speaking, to have something similar to the OASIS by the years 2040 or 2050?

I certainly do, we are already advance with augmented reality technology and virtual worlds, so it's just a matter if time.

References:

Lacero by Andy Weir: Lacero.

Ernest Cline. Ready Player One. Broadway Books, 2011. ISBN: 9780307887443

WarGames

WarGames is a really interesting movie of the 1980's which talk about how technology was viewed in those years.

The premise is that a smart boy is able to enter to the Department Of Defense database and he discover a game which turns out to be a simulation for a real world war. So the the story moves around the kid trying to undo his mistake.

In the 80's it was believed that computers could be of great danger, if someone unauthorized get in, could administrate the launch of the misiles, bank accounts, etc. So this movie was a perfect example of that. Once the boy began the game, it (the game) took control over the United States DOD machines and show in the screens what was actually happening in the simulation, making everyone believe that Russia was actually preparing for the third world war.

Eventually the scientists discover that it just a simulation taking place, but still everyone just keep playing alone with it (movie stuff I suppose). So the boy go to the man that created the simulation in order to make everyone come to reason. But by the time that happens, the simulation has already stolen the codes to launch every USS misiles. So now the problem is how to make the machine knows it is only a simulation and it could never win the war. Lucky for us, the program has a really good artificial intelligence so by playing "tick tac toe" with himself over an over again it discovers that there are some games that are impossible to win. The simulation begins to compute all the possible result of wars with every country and sees that there's not a possibility to win either way, so it aborts the simulation and everyone is happy.

Reference:

“WarGames” directed by John Badham in 1983.

Microservices

This week we read the article "Microservices" by James Lewis and Martin Fowler.

The microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.

Enterprise Applications are often built in three main parts: a client-side user interface (consisting of HTML pages and javascript running in a browser on the user's machine) a database (consisting of many tables inserted into a common, and usually relational, database management system), and a server-side application. The server-side application will handle HTTP requests, execute domain logic, retrieve and update data from the database, and select and populate HTML views to be sent to the browser. This server-side application is a monolith - a single logical executable. Any changes to the system involve building and deploying a new version of the server-side application.

Characteristics of a Microservice Architecture

- Componentization via Services

When talking about components we run into the difficult definition of what makes a component. Our definition is that a component is a unit of software that is independently replaceable and upgradeable.

Microservice architectures will use libraries, but their primary way of componentizing their own software is by breaking down into services. We define libraries as components that are linked into a program and called using in-memory function calls, while services are out-of-process components who communicate with a mechanism such as a web service request, or remote procedure call.

- Organized around Business Capabilities

The microservice approach to division is different, splitting up into services organized around business capability. Such services take a broad-stack implementation of software for that business area, including user-interface, persistant storage, and any external collaborations. Consequently the teams are cross-functional, including the full range of skills required for the development: user-experience, database, and project management.

- Products not Projects

Microservice proponents tend to avoid this model, preferring instead the notion that a team should own a product over its full lifetime. A common inspiration for this is Amazon's notion of "you build, you run it" where a development team takes full responsibility for the software in production. This brings developers into day-to-day contact with how their software behaves in production and increases contact with their users, as they have to take on at least some of the support burden.

- Smart endpoints and dumb pipes

The microservice community favours an alternative approach: smart endpoints and dumb pipes. Applications built from microservices aim to be as decoupled and as cohesive as possible - they own their own domain logic and act more as filters in the classical Unix sense - receiving a request, applying logic as appropriate and producing a response. 

- Decentralized Governance

Teams building microservices prefer a different approach to standards too. Rather than use a set of defined standards written down somewhere on paper they prefer the idea of producing useful tools that other developers can use to solve similar problems to the ones they are facing. These tools are usually harvested from implementations and shared with a wider group, sometimes, but not exclusively using an internal open source model. Now that git and github have become the de facto version control system of choice, open source practices are becoming more and more common in-house.

- Decentralized Data Management

Decentralization of data management presents in a number of different ways. At the most abstract level, it means that the conceptual model of the world will differ between systems.

- Infrastructure Automation

Infrastructure automation techniques have evolved enormously over the last few years - the evolution of the cloud and AWS in particular has reduced the operational complexity of building, deploying and operating microservices.

- Design for failure

A consequence of using services as components, is that applications need to be designed so that they can tolerate the failure of services. Any service call could fail due to unavailability of the supplier, the client has to respond to this as gracefully as possible. 

- Evolutionary Design

Microservice practitioners, usually have come from an evolutionary design background and see service decomposition as a further tool to enable application developers to control changes in their application without slowing down change. Change control doesn't necessarily mean change reduction - with the right attitudes and tools you can make frequent, fast, and well-controlled changes to software.

If you are interested in reading this article, here is the link: Microservices.

The 4+1 View Model

This week we review two videos and one little article.

Video: 4+1 View Into Software Architecture
UML has several ways to describe how our system will look like. And so we can divide in Structure diagrams, Behavior diagrams and Interaction diagrams which define the mechanical or technical structure of the system, how the system is expected to behave, and how the system is expected to interact with other components or systems.

But UML is not the only way to describe how a system works, we have several different tools as: Use cases, Class diagrams, Deployment diagrams, Sequence diagram, State machines.
We have a special view which will help us achieving the same results: it is the "4+1 View Into Architecture" which is mainly describe as (4 views) Logical View, Development View, Process View and Physical View, and the (+ 1) Use Case View/Scenarios.

- Logical view: What sort of objects we are going to be building for the product.
- Development view: How the system is organized also called Implementation view.
- Process view: describe the concurrency and synchronized aspects of the software.
- Physical view: how the software and hardware are related.
- Use Case view: Explanation of how the system is expected to behave.
All separate but complementing each other.

Video: Six Blind Men
This video is about 6 blind men who touch an elephant to know how it looks like. The thing is that each of the blind men touch a different part of the elephant having each a different opinion of what an elephant looks like. At the end they all have a fight because no opinions are the same, even though they all touch the same animal.

Article: The Elephant and the Blind Programmers by Grady Booch
This is a little story about 5 blind programmers, as the story of the last video, this story is about an animal that arrives to the the town and 5 blind programmers approach to see what animal is it about. They all touch a part and made their own opinions and begin to argue. Finally a wise man Rashomon, tell them that they are all correct but each one of them is looking the animal with their own perspective and knowledge. So, in truth, the creature has all the characteristics that they all have observed.

If you are interested in watching these videos here are the links:
4+1 View into Software Architecture
Six Blind Men

Link for the article:
The Elephant and the Blind Programmers

Understanding the SOLID Principles

The article called "Understanding the SOLID Principles" written by Edward Guiness is a brief summary that present us the definition of the "SOLID Principles" which is a set of principles that seeks to implement best practices in the creation of objects and classes in specific cases depending on the situation that is presented in the moment. The SOLID word is an acronym that is used to include the Single Responsability Principle (SRP), Open/Closed Principle (OCP), Liskov Substitution Principle (LCP), Interface Segregation Principle (ISP) and the Dependency Inversion Principle (DIP).

The first principle, the Single Responsibility Principle is a principle that focuses on the creation and verification of classes that should have exactly one responsibility which makes the classes more clean in the sense that the classes have only ONE well defined responsibility to do which is a practice that prevents that the modifications implemented in one class cause problems in other areas that apparently are detached of the principal responsibility of the modified class. 

The second principle, the Open/Closed Principle establishes that a class or function should be open for extension but closed for modification which show us that a class have to be constructed in order to be flexible and adaptable for the conditions that exist in the particular situation and that this class doesn't have to be internally modifiable from outside.

The third principle, the Liskov Substitution Principle on the other hand establishes that two classes can be interchangeable where these two classes have an inheritance link between them which provides a characteristic of flexibility to the function.

The fourth principle, the Interface Segregation Principle establishes that is worse to have an interface that to have to do a lot of tasks that many interfaces that have these tasks spread between them causing that the work accomplished for one specific interface is only the required work and the fifth principle , the DIP, establishes that a class have to use interfaces or abstract classes instead of refer to actual classes making with this that the dependency between the classes is diminished and that the class that implements the interfaces can use another interface in an easy way, which is related with the objective of the LCP in the way that the two promote the adaptability of the classes. 

After reading this five principles I can say that when programming we should be aware of them because they help us have a more structured code, cleaner and therefore more readable. Also with these techniques we learn other things about programming and we can make better programs with better quality.

If you're interested in reading this article, here is the link: Understanding the SOLID Principles.

Software Craftsmanship with Bob Martin

Bob is a software developer but he is also an architect, but what he do love is developing software. He thinks architecture is really worth doing, but he thinks architects should be also coders because otherwise they don't connect with the code decisions, "they don't connect with the keyboard", they just forget the code, and doing it that way the architect just forgets about the keyboard and it's really hard to manage a team like that.

The software craftsmanship according to Martin is the way where new people that are involved in the development world can learn from the more experimented people in the industry, the people that can be named a "master" or "mentor" which tasks are share all the knowledge, skills and tools with the newest individuals in the industry in order to create a system where the community can grow from inside being powered by its own people. This idea is really amazing because like Bob says, is very cool that being a programmer can be equal to be a lawyer or doctor, where all the knowledge is flowing from one person to another changing the way in that the community works, transforming it in an environment where solidarity and the teamwork can help to reach the individual and collective success. 

Some important things that the implementation of a system like this can bring in a positive way is that the professionals can learn the correct ways of developing some type of product, improving and honing their programming skills in order to change their habits, turning them into disciplined people concerned about the way how they work and think, moving this into the practice where it can see it reflected in the product quality. 

Now, the "Manifesto of Software Craftsmanship" is a good example of how very important advices can be written in a few lines of text where the important ideas are summarized in four principal advices that tell us like programmers that if we want to be better professionals following the software craftsmanship we have to be aware of helping others to do quality software, response to the change and add value to the product with it, strengthen the community of professionals with my contribution and search a good productive partnerships in the projects. 

One of the key points in here is to test in development, that gives them a lot of points. They run unit tests, every line of code is tested. It reduces danger.

Something really interesting that he explained is that all programers should know at least one funcional language, dynamic language, static language and logical language, in order to have a good knowledge of everything that industry may ask.

Nowadays there are dynamic languages like ruby or python that use this type of tests, and they're dynamically typed. What the author recommends is to learn as much languages as possible, that is, to be able to write code in that language, that gives many points in software craftsmanship, you improve your own skills and in that way you improve your craftsmanship. You should learn at least one dynamic language and one static and he thinks that everybody should learn Lisp.

If you are interested in listening to this podcast here is the link: Software Craftsmanship with Bob Martin

Is Design Dead?

Programming is an activity that involve a lot of dedication and passion because in most of the cases the fact of doing a good program from scratch is something that can be a really easy or difficult task, all of this depending of the person that it's in charge and its abilities involved in the planning and design of how to do the task.

Like Fowler (2004) mentions in his article "Is Design Dead?", that in the software development context exist to ways that the person in charge of developing a program can choose which are "evolutionary design" and "planned design", where the first means that the design of the system grows as the system is implemented and The other approach is called planned design, where the designers think about the big issues in advance, there's no need of coding, they just build the general part, and they handle the result to other team, let's say "the programmers team" to actually code the design. Of course, it is practically impossible to think of all the issues you may have, before actually having something, so when you are programming there are questions that emerge about the design, and changing the whole design, yes that's also a lot of work and not all the time works, cause, what if the designer is gone and you cant understand?. So we have a big problem here and it is called "changing requirements". Some say that building the design kinda flexible, leads us to a good way to change our requirements. Thanks to some practices provided by the XP (Extreme Programming) as continuous integration, testing and refactoring, among others, this way can be a very good option.

The XP uses evolutionary design but with the underlying assumption that it is possible to flatten the change curve enough to make this design work, so that for example a change made in analysis for $1 doesn't cost thousands to fix in production. So, in XP they need several things to get this working correctly, first of all they need continuous integration to keep the team in sync, refactoring, which makes the code more understandable and finally, testing; with these three things, XP can achieve its results using evolutionary design.

One of the most important things XP relies on, is "Do the simplest thing that could possibly work" and "You ain't going to need it". So what I understood here is that we don't have to code features that are not gonna exist yet, because we don't even know if we are gonna need them in the future, and the design becomes more complex if we do this. To make our code simpler, XP gives us a criteria for our system: it runs all the tests, has no duplication, reveals all the intention and has the fewest number of classes or methods. Another point here is to refactor, because even though it doesn't add function, it makes our code simpler, so we should refactor every time we can.

Now, all the above is information that proof that the design is not dead, is like Fowler says "changing" and this give us to the programmers the idea that the design doesn't have to be avoided of the process of how to do the task of making some program because the design is the warranty that the program is going to result as a high quality product where the software entropy doesn't exist or is very small. This also proof that the software architecture is a very basic aspect of a process where is involved the development of a program because this activity allows to include the foundations in which all the rest of the elements are going to be based and related which is something that secure the good quality of a software product.

If you're interested in reading this article, here is the link: Is Design Dead?.