Ethical Reflection on Ready Player One

Ready Player One is a novel about a distopic place in the future where whats initially was a videogame, turned into a new world, where people interact with each other in that place instead of actual human contact.

I think the quotations are true because the world turned into a very dark place, where people had real problems, and the only way to escape reality was to get in the game, to get into their fake lives where they could, at least for a moment, forget about their real life problems, but by doing that, the never actually solve those problems, which caused more and more, until the real life was so stressful they prefer to live in the game forever.

I think OASIS has some virtues, not as many as defects, but one virtue is that people could meet other people from anywhere in the world. But that also means that laws need to exist to regulate the things that the people can do on the platform, because initially, all the game characters could do anything they wanted as long as they have the money to buy things.

With all the technology industry evolving so fast in the past couple years, we are starting to see some behavior like we saw on the novel, people sometime prefer to talk to people using a messaging app, instead of actually going out, or there could be 5 friends in a room but they don’t talk to each other because they are on their phones. Another thing I see is that for us, money is starting to become just an account number, there are less times where people buy thing with actual physical money and buying the stuff they need over the internet, so we are not that far of a reality like in the novel. While there are some things on the novel that are impossible to implement in real life, most of the essence of the game could be a reality in a couple years.

Hidden Figures

For this week, there is no article, last class we watched the movie called “Hidden Figures” which talks about a bunch of black women that were facing different situations that relates with racism and sexism. They were part of the NASA team, which at that moment (the 60s) were trying to make a man go around the earth in space, but they were trying to beat the russians on who could accomplish that first. The russians make some important achievements before the americans like getting a man on space, because of that, the americans needed to get a man to go around the earth and safely bring him back to american soil.

At the NASA offices, there were a bunch of black women who were extraordinarily good with math and numbers, they did all computations before the computers as we know them today were a thing. At the time, black people didn’t have the same rights as white people, they even needed to use a different restroom.

The team that was working on the project, needed a good “computer” (computers on this context were those brilliant black women), so they asked Katherine to be their computer, this was unheard of, and when she got to the workplace, there were a small amount of women, and no black people, so she and everyone there were very confused (they even got a coffee mug for black people!). She tried her best to deliver the expected results, but because her gender and skin color, everyone there underestimated her work. Meanwhile, her colleges watched a new generation of computers arrive, this time weren’t humans, so they thought that the machine would replace them, which was the objective, but the team in charge of that computer weren’t able to get the expected results from it, so Dorothy stole a Fortran book from a library, so she could learn the language and operate the machine. This is something I think needs to happen more frequently, especially on this moment that software is taking some peoples jobs, I admire her for her courage.

At the end Katherine was able to show her colleges that she, as a black women, was as capable as every person on the room, and because of her, the project was successful. This was a lesson for the society that a person shouldn’t think that people, because are different, shouldn’t have the same rights as me.

Microservices

This weeks article is about microsystems. Software in the past and some software currently have a monolithic structure, that is, all the services and utilities the system needs, are in a single server and all the code is in the same project. This has some advantages, for example, it is easier to connect software components and services because the developer or the team knows how other services work and will produce and receive data, but it also has many disadvantages, mainly, if something on the project breaks, it will affect the entire system. On the other hand, we have microservices that could be useful for many services and have many applications, for example, if one of the services is not crucial for the entire system functionality, if it fails, all other modules that doesn’t use that service could operate without any trouble, but a disadvantage could be that all modules need to use a standard, otherwise, they wouldn’t be able to communicate with each other, but on these days, almost every microservices uses http for passing information, and JSON for the structure of that information.

There are some characteristics each microservice needs to have to function properly, those are:

Componentization via Services: Components need to be broken up into services, so that they can be used as libraries.

Organized around Business Capabilities: Split the people into team so that they all can work with teams on specific business capabilities.

Products not Projects: Software has to be meaningful, it needs to provide the client with a useful product to make his life easier, instead of just a bunch of code.
Smart endpoints and dumb pipes: Endpoints should do all the heavy lifting when it comes to the computations, so the pipes only pass informatión and could be less cluttered.
Decentralized Governance: Developers need to have the skill to learn any language or technology the product needs, they should adapt to the basic idea, instead of adapting the idea to the language or the technology they know best.
Decentralized Data Management: Each microservice should use it’s own database, or different instances of the same database.
Infrastructure automation: automate all things, including testing and deployment.
Design for failure: If an external service fails, the current services should be able to handle all kinds of errors
Evolutionary Design: The code should be design in such a way that could be easy to evolve depending on the business needs.

The 4+1 View Model

For this weeks blog we did several things, we watched a video about the 4+1 view model, we also watches a short video about six blind men which tried to identify and object (an elephant) and tell what it is, finally, the article we read was about more or less the same, but with software in mind instead of an elephant.

Starting with the 4+1 view model, the video started talking about uml diagrams, which I am a bit familiar since I’ve used them from the start of college until now to create a model of an Object Oriented system I’m about to code. It is helpful to get a general idea of what needs to be done and how. In this diagram, the programmer has to state every class and method is going to be used, also if there are environment variables, so that the only thing to do after that, is focus on the functionality of each method and how classes interact with each other. Also with the uml, the programmer could detect flaws in the model, which is a good thing because as we know, the earlier we detect flaws in development, the better.

The first model is the logical model, which contains all the diagrams and models we are going to use to start our project.
The second one is the development model, which is when developers start coding, choosing the correct programming language and the correct libraries.
The third one is the process view, which is about concurrency of the programs.
The fourth one is the physical model, which is how the software interact with the hardware its going to be used.

And finally, the +1 model is the use cases, namely, how the system interacts with the users, the input the users gave and the scenarios the software could be in.

The second video and the article are related, because they talk about people that don’t have all the scope information of something, so they start to construct their own opinion of that they think the software (or the elephant) is based on the information and the point of view they have.