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.

Understanding the SOLID principles

Last week we listened to a podcast where Bob Martin was interviewed about software craftsmanship and techniques to make coding better. He also developed 5 principles he recommends to enhance object oriented programming, which are the following:

• Single Responsibility Principle: This is that the class we are working with, needs to be useful for one thing and one thing only. In a previous text, we learned that we could use compositions to avoid making several things on one class. The theory is easier to grasp than the practice. In practice, you must rely on experience and common sense. Not following this practice may end up in a developer really frustrated trying to understand what the class is doing.
• Open/Closed Principle: Any class should be open for extension but closed for modification. For that we probably need the skills Bob mentions on the past article, so we gain experience with making code difficult to break, and at the same time, be accessible, easy to understand and introduce new functions and features. The principle means that when adding new behavior you should leave base classes alone and instead create new, inheriting classes
• Liskov Substitution Principle: This principle is in charge of  keeping the happy working relationship between classes and functions alive and well, when one class inherits from other. Experience tells us that changing the behavior of a class in many cases leads to problems elsewhere in a code base. It is another example of how you should strive to minimize dependencies of all kinds in the interest of writing robust and maintainable software.
• Interface Segregation Principle: Avoid writing huge interfaces that give classes a lot responsibilities they don’t need or want. The developer needs to have the ability to instead create a collection of smaller, discrete interfaces, partitioning interface members according to what they concern.
• Dependency Inversion Principle: This principle means is that instead of writing code that refers to actual classes, the developer should instead write code that refers to interfaces or perhaps abstract classes.

Software Craftsmanship

Bob Martin gave an interview about craftsmanship software and agile software techniques, which are directly correlated, because craftsmanship tries to up the developers skills and the agile software techniques are the ways a developer could improve them. Bob also thinks that they have a lot in common.

Bob talks about how we, as developers, get the craftsmanship of the software when we are in our jobs, in some sort of trial and error manner, this happens as we are building our skillset so we can build better code faster, but Bob thinks the developers need to learn this things on school, so instead of trial and error, it could be more like an educated guess. I’ve learned a lot of nontechnical things on my jobs, things that may take too much time to put them on a course, also, seen those things in practice helps clarifying a lot of things a developer may not understand with the theory.

We also try to develop our agile software techniques so we can solve our coding problems faster. Companies learn from their and others mistakes, so they create standards to ensure the employees get the right focus on the right skills, so they get small things done very quickly, making easier the error detection. This agile techniques, allow developers to get things done in less time and focus on bigger problems.

Not all college developers have a good craftsmanship, because not all have the opportunity to get a job o just don’t want or have the time, but this skills are necessary for the developer to get their work environment ready in no time when they get their first job, that’s the reason students need to get that experience from bigger college projects or projects that are not necessarily part of any course.

War games

War games is an 80s movie that talks about a machine that could simulate several war scenarios depending on the current conditions of each county involved in that specific war. This machine was created because there was a test for soldiers if they would be able to turn a key to activate a nuclear bomb to kill dozens of people. Turned out, soldiers weren't able to turn the key because they thought of all the people that bomb would kill, so this machine was built because doesn't really care how many people die if it needs to throw a bomb.

In the other hand, there is a geek guy called David Lightman that isn’t really interested in school, but he is really good at computers. So he change his and a friends grade so they pass the course. The movie were filmed in the 80s, so the internet was very different, he had to connect through dial up, so he put his computer to dial all numbers in the area of a videogame company so that he could get info on a game that isn’t out yet, he found what he thought was the company's files of its games, but then he looked that there were games with strange names like “global thermonuclear war”. That game ends up being the machine the government created to simulate the wars. The machine was created by Stephen Malken, who was an AI researcher when the machine was built, so it could learn more as the simulations were finished.

David started playing with the machine as the Soviet Union not knowing that he really started a simulation that would trick the military into thinking they were under attack. They tracked David down and explain to him what he has done.

The machine can’t really tell that the US is under attack, so he tries to launch lots of missiles. David tried to convince Stephen to help him stop the machine. He realized that the machine won’t stop playing even it has no chance of winning, so he put the machine to play tic tac toe so that the machine learns that there could be no winners, so it applies that new concept to the war simulator and discovers that, in some cases, the only way of winning is not to play, so the missiles were not launched.

Is Design Dead?

Is Design Dead?
The article talks about how the design has evolved over the years, and developed good practices to create a good design with ease.

Like in other areas, we, as developers, have tried to develop a way to create good design. Many other areas already have good standards on how to create a good and effective design, but in computer science, we’ve still not refined the methodology just yet. But we’ve discover some things that make a good design, for example, our code has to be somewhat modular, it has to be easy to alter, because the system probably won’t stay the same for the rest of the days, it’ll probably need maintenance, so a good design, should allow easy maintenance and the new features should be easy to incorporate. It is harder to modify a design in the middle of the development, even if the changes are good, because things need change to adapt the new design and there could be more bugs at the end.

Design should be done before development. Designing the software while it’s being built could end on a project with no Quality Assurance, it could take longer to develop and most likely have a lot of bugs. The software designers first create the design of the entire project, so they can get all the informations and sort the bigger problems, so they are not distracted by the technology programmers use. Then programmers follow the design so they don’t have to worry about other stuff.

Software should be simple, the team has to be focused on what is important now and build only the features needed, they don’t need to waste any time and resources building features that could be used in the future. This is, creating the least amount of code possible. Reusable code should be used properly, so that there is no duplicate functionality.

Who Needs an Architect?

The article is about how software architecture can be seen as two different things, one is that the architect understands the general scope of the system, so that he makes the correct big decisions, the other one is that the architect tries to solve all the issues possible.

To me, the first one fits what I think of an architect, I think a software architect should be someone that builds the general idea of the project, divides it into small chunks of important stuff the system has to do. The technology that needs to be used doesn’t matter to the architect at the early stages, the team first needs the requirements of each of the components of the project to decide, based on the requirements what kind of tech or programming language they are going to use. As we can see, that is pretty similar to the first definition the article gives.

Also, the article talks about how the architect could make thing easy to change, so we don’t need to know all the specifics of the project at the very beginning, so we can avoid complexity in the system when we need to make a significant change, but making some things easy to change, the system gets more complex, and if we make everything easy to change, the system gets very complex, so we defeat the purpose of trying to make the system less complex in the first place.

Many authors make the comparison to building architecture, which in many cases makes sense because there are a lot of similarities, but the article makes an excellent point, software architecture is not limited by physics, so, in many cases, software architects have a lot of freedom, but that could be a double edge sword, because it is easier to make a mess.

Fowler, M. (2003) Who needs an architect?. IEEE Software.

Who needs an achitech

The article is about how software architecture can be seen as two different things, one is that the architect understands the general scope of the system, so that he makes the correct big decisions, the other one is that the architect tries to solve all the issues possible.

To me, the first one fits what I think of an architect, I think a software architect should be someone that builds the general idea of the project, divides it into small chunks of important stuff the system has to do. The technology that needs to be used doesn’t matter to the architect at the early stages, the team first needs the requirements of each of the components of the project to decide, based on the requirements what kind of tech or programming language they are going to use. As we can see, that is pretty similar to the first definition the article gives.

Also, the article talks about how the architect could make thing easy to change, so we don’t need to know all the specifics of the project at the very beginning, so we can avoid complexity in the system when we need to make a significant change, but making some things easy to change, the system gets more complex, and if we make everything easy to change, the system gets very complex, so we defeat the purpose of trying to make the system less complex in the first place.

Many authors make the comparison to building architecture, which in many cases makes sense because there are a lot of similarities, but the article makes an excellent point, software architecture is not limited by physics, so, in many cases, software architects have a lot of freedom, but that could be a double edge sword, because it is easier to make a mess.

Fowler, M. (2003) Who needs an architect?. IEEE Software.

Software Architecture

Software architecture is a very important phase on a project, because it can present all the parts or the
necessary things it will need. By having a greater context, not just, single functions, the software
architect could review the “blueprint” in search for errors or requirements not totally satisfied.

At this stage, a change on requirements is not a huge deal, like we saw on software modeling, a
change on requirements will cost more time and money as the project is close to completion.

As Googliffe stated in his book, we need to find a balance between the software’s architecture
being too general, that we can’t understand the scope of the development, or too specific,
that a simple change of requirements will have a big impact on the design.

All software projects need some sort of architecture if they need to be finished on a reasonable
time, even the smaller ones. As the project becomes bigger, it’ll need a bigger architecture,
but it has to still be compact, so everyone, even outsiders of the project, could get a grasp of
what the project is about.

I think the examples given of software architecture comparing it with building architecture is
great because they have same type of success on the project, and a change once the project
has begun, could compromise the reliability of the project and could not be ready for launch on
the due date.

The architecture is about knowing what components of software do, and how they interact with
each other. The implementation and how they work isn’t on the architect’s worries.

Not all software is created equal, so there are many styles to create an architecture. For starters,
we need a good architecture, a project with no architecture most likely will produce more problems
than it solves, “cheap gets expensive”. The most common is the layered, which stacks components
as if they were blocks, one on top of the other, so the top components doesn’t get affected if a lower
component gets changed. The pipe and filter are just components that take data, modify it and pass
it so other components can do the same. The client-server just relies on a external computer(server)
to do the heavy lifting, and then it returns data to the client. Component-Based architecture works
by dividing the project into smaller pieces which talk to each other, all of them solving different
tasks. Finally the Framework is just a collection of predefined methods and functions that a
developer can use to simplify the project and waste less time.

Goodliffe, P. (2006). Code Craft. S. Francisco: No Starch Press.

Moon machines

On Monday, we watched the "Moon Machines: The Navigation Computer" documentary, which is about the Apollo program that the NASA put together to take the man to the moon, and how the MIT used the technology they had at the time to create a computer to guide the spacecraft.

All started because John F. Kennedy gave a challenge to the NASA: landing a man on the moon. NASA put the MIT in charge of the system that guided the rocket to the moon.

As a software engineer, I really appreciated the work of Margaret Hamilton, because we’ve seen the photo of Margaret Hamilton standing next to a pile her size of paper, which contained all the necessary code that the computer needed to reach its goal.

Another interesting part of the video for me, was all the work put into creating a gyroscope, which was fairly big instrument which they tested on an airplane and discover some flaws. This sensor is something we take for granted today because we can find one on the phones in our pockets. Sure, it’s not as precise as the one used to take the man to the moon, but it is amazing the kind of work they did with old technology the had at the time

All calculated data needed to be as close to perfect as possible, because one little flaw on any of the systems, could mean a disaster to the program, so the quality control was extraordinary strict, so many components were rejected.

Today, we’ve seen and heard a lot of people saying the moon landing didn’t really happen, so it's good to have all these engineers talk about their experience on the program because this kind of documentaries help us understand how they actually did it and help clear people's doubts, which are part of why didn’t believe in the first place.

Introduction

Hello everyone! My name is Pablo Alejandro Sánchez Tadeo, I prefer Pablo, but either one is fine. I'm majoring in Computer Science and Software Engineering an the Institute of Technology and Higher Education of Monterrey, currently on the seventh semester.

First I thought this class was some kind of class we would take with Prof. Humberto about the methodology to create great software and how a complete system is created from the ground up, which I think it could have something of the latter, but from the intro class and the fact that we'll use aws, my expectations of the class have changed a bit, so I'm open for surprises!

I'm currently working as a back-end software developer using python and neo4j, which are not the typical tools I've used in the past. I like them because I've never used them so I have to learn new things and expand my vision.

I love cars, how they work and what they can do. Also love driving (when there is no traffic, otherwise I hate it a bit). I could spend hours staring at a good car and knowing about them. It is my second passion after Computer Science. I think it's because I generally like to know how things work.

As for the hobbies, I like to play the guitar, I mainly enjoy hard rock and blues, but I like to listen to several genres, from jazz to electronic music. Also I love food and trying new things, I like trying the typical meals someone would have on every place I go. México has a great gastronomy and I like most of the things people around the country eats.

My favorite trilogy of movies is Back to the Future. I think the concept is well executed. Also love that was made in the 80's and it shows that culture as well as the 50's and what they thought the 2010's would be, which are the decades they travel to in time.
One tv show I like is Stranger Things. that show also shows how living in the 80's was, and it too is science fiction.
Another tv show I watched is sense8 and i liked it because shows life when you share your mind with 7 other people, and how each person has a special skill that could help others solve their problems.