Ready Player One

For this final entry, we are going to talk about Ernest Cline book "Ready Player One", which gave us a pretty interesting adventure, that personally I liked it, so the purpose of this entry is making a reflexion, taking as a starting point, the next two paragraphs:

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 un can find true happiness. Because reality is real" (p.364)

First of all, I'm gonna begin with the if I agree with the quotations before? And the answer is yes, because as their perspectives, they are right, reality is hard so we find ways to escape from it, but at the same time, as everything, if we escape too much it can be harmful and we can lost the sense of reality, so there should be balance between them. About the virtues in OASIS I think, the are many like loyalty, like Daito y Shoto, they were not brothers but they acted like that, also perseverance to find the keys and solving the puzzles, so there are virtues I found in the book.
Our value system it could be altered if we spent most of the time in an OASIS like system, because there are histories, were you loose the sense of time and reality, our costumes will be altered and the lost, because if we made a comparison with our current use of IT technologies like computers, game consoles, smart phones, and social networks (Facebook, Twitter, Instagram, Pinterest, etc) with the OASIS game at the book, the is no big difference, games had change their role, now all is virtual and practically the new generation born with technology, so it is no gap between the reality we live and the book. We live with IT technologies in our daily life.
I think all this books like Ready Player One, Nineteen Eighty-Four, The Hunger Games, The Matrix, etc, for so creepy that it sounds, have a little bit of truth, I mean it's like predicting future, but the worst part is that most of the time we did not notice about it, obviously it is not the 100% of what happen in the real world, but we are getting closer.
So, I think it is possible, technological having a similar OASIS nowadays, because now games have evolved to the point we can connect with people from the other part of the world and so on, the tools now are pretty closer for an OASIS game, also reminded me to the Spy Kids 3, where was kind of game of the book, but less interesting. And the fact that video games are pretty addictive isn't it?

References
"Ready Player One", by Ernest Cline

An Introduction to Metaprogramming

Hi everyone! On this entry we are going to talk about metaprogramming written by Ariel Ortiz. First of all, we need to know that a metraprogram is a program that generates other programs or program parts, which is helpful when we want to generate source code, but before we can do this, we need to know the adequate tools to make that magic happen!
The article show us an hypothetical situation, were metaprogramming is the solution, so if we want to write an extense source code, without doing manually or using loops, the only thing we can do is write a program that creates it, so the example they show us, is print a sentence too many times. And that is an easier way, also we can do it with images. Another thing, we can do is generating source code and execute it on the spot, only calling eval, which is a function some languages have, allowing to translate and execute an piece of source code contained. This feature is mostly available on interpreted languages as Lisp, Perl, Ruby, Python and Javascript. But eval, can have it's disadvantages, like can be insecure, that's why it exist an other alternatives as quines, quines are defined as a program that generates a copy of its own source text as it's complete output. Another advantage of metaprogramming is the possibility of modifying programs during Runtime.
So, after reading this article I think or I agree that metaprogramming is not only for programming languages gurus, the important here is knowing the tools of each programming language as eval. And metaprogramming have the advantage that for larger programs, we can write a program to do the tedious work, but I think the hardest part is knowing how to write a program that write programs, so it's important knowing the techniques.

For more information visit An Introduction to Metaprogramming by Ariel Ortiz.

Microservices

Figure 1: Monoliths and Microservices

Microservices is a term, that makes reference to an architectural style, meaning that a single application is developed as a small service. To understand better the term, the article make a contrast of what monolithic style means, and is a monolithic application bit as a single unit. An example, is the server-side application of an enterprise application, which handle HTTP requests, execute domain logic, retrieve and update data from a database; but the truth is that any small change to the application, require the entire monolith to be rebuilt and deployed, which is a pain.

So, that's why microservices are a way more better, because services are independently deployable and scalable; and allowing that different services can be written in different programming languages. Graphically, in Figure 1 we can see the differences between monolithic and micro services. But the truth is, that all not all the micro services have the same characteristic (but we expect the opposite), which are:

• Componentization via Services
• Organized around Business Capabilities
• Products not Projects
• Smart endpoints and dumb pipes
• Decentralized Governance
• Decentralized Data Management
• Infrastructure Automation
• Design for Failure
• Evolutionary Design

So the main question is are Microservices the future? Despite the experiments and comparison made with the monolithic architecture, micro services have many advantages, but we need to consider that we can take a final decision, because architectural decisions are only evident several years after you made them, so is soon to make a final decision.
So from my point of view, seem to have so many advantages the micro services in contrast with monolithic, but taking in count the requirements of the system and implementing a new architecture involves too much time and money, that's why I think, not many companies have adapted this architecture. One good example of a website that knew who to use it is the The Guardian website, which the core stills built as monolithic, but they added features by building micro services that use the monolith's API.

Santorini, Greece

For more information visit Microservicies

The 4+1 View Model

The main topic of this blog is the 4+1 View Model, but we are going to complement it with another article and video, that in brief is about how blind men try to describe one creature, but their perspectives are so different, that did not get to a final decision and that's what happen when we try to build a software or in project if we see that way. So the article The Elephant and the Blind Programmers is kind of the video of the Six Blind Men, but the moral that one describe us is that a methodical war, where everyone fights to prove everyone is wrong, except him, but the truth is that everyone is right, about some part of the creature, but if they would join all their opinions, maybe it would be easier to came to a result, and that what the article tried to teach us. Mention this, we can now talk about the 4+1 Model, because what we mention before was like an analogy or the consequences of not having a good methodology, and this model is about four views, plus one that is an use-case view, which we will describe next:
Logical View. Tell us what sort of objects we are going to be building for the product. Include all the classes and objects, how they communicate and the sort of data.
Development View. (Which belongs to what) Tells the developer how the system is organized during the development. Also called implementation view.
Process View. Describes the concurrency and synchronized aspects in the process and software.
Physical View. Tells us how software and hardware are related. How the system will look like, when is in the system environment and what parts of the system goes where.
Use-Case View. This is the +1, also called scenarios, which describe is how the system interacts with the world
So this are important for developing software and having a good organization, to avoid situations like the blind men.
For more information visit 4+1 View into Software Architecture

Six Blind Men
The Elephant and the Blind Programmers

Understanding the SOLID Principles

First of all, SOLID is an acronym for the it's five principles hidden in each letter of object-oriented programming (Java, C#, PHP, Python, Ruby, etc.) and design. It's objective is to avoid dependencies, because it may cause problems on the code if there are, so the principles are:

• Single Responsibility Principle (SRP). Basically as the name said the method should have only one responsibility, because the consequences would be at the moment of maintenance, when other programmer change the code and if the class do two things, but the programmer did not check out, the functionality would be compromised.

• Open / Closed Principle (OCP). It states that a class or function should be open for extension and closed for modification. Meaning that the base classes (functions) should be leave alone, when adding a new behavior and create new inheriting classes. It's about inheritance.

• Liskov Substitution Principle (LSP). This principle is like OCP and has the intention to keep happy relationships between classes and functions to work well. Meaning that as the previous principle said, avoid modifying the base class with the difference that LSP do not use the inheritance mechanism (because it would be a violation to the principle), instead of that, create an instance of that class. In other words, avoid inheritance by using keywords according the language, for example in Java you can use final keyword an in C# sealed keyword.

• Interface Segregation Principle (ISP). This principle is about interfaces and avoiding creating too many responsibilities in one interface, making the code less understandable, it's kind of SRP but with interfaces and with the main difference that you should partition interfaces according it's concerns, making the code more readable for other programmers.

• Dependency Inversion Principle (DIP). "Depend upon abstractions, not upon concretions" Meaning that you shouldn't depend of another class, instead it's better depend from an interface, becoming easier to substitute any class you want.

From my point of view , already having understood the principles gave me a new way of code, because sometime we do not follow a standard when coding, but we may ask Why this is important? Dependencies are always there, but the less we avoid the easier it's maintenance will be.

Vatican City, Rome

For more information visit Understanding the SOLID Principles

Software Craftsmanship with Bob Martin

Bob Martin is an software architect, also known as "Uncle Bob", but before that he said he was a little bit of everything, because people need to grow. 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 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.

 It is important to mention that there is too much importance in the developers teams related to collaboration and having good practice in a way to  be sure that all members of the team  are informed with the all related to the project and we have to keep in mind coding considering that in the future we want to change something, so the code must be able to change without breaking something else. In conclusion, Bob Martin have a lot of knowledge of how to this Software Craftsmanship Manifesto works, and is important knowing the point of this, to future generations. 'cause at it says, knowledge is everywhere and we need to use that, to get this new industries that want the best of the best, specially with software architects.

Piazza San Marco, Venice

For more information visit Episode 150: Software Craftsmanship with Bob Martin

Is Design Dead?

As we know Extreme Programming (XP), created by Kent Beck is a methodology of software development that according to the author Martin Fowler it is calling the death of software design, so our main concern Is Design Dead? to give a better understanding and answer to this question he gives us step for step many arguments to be or not in accordance with the author.

In software development there are many styles of design, but the author described us two; one of those are evolutionary design, that means the design of the system grows as the system is implemented, but at the end it's a bad idea because makes the code harder to modify going against the practices of XP. On the other hand we have Planned Design that works the same with the disadvantage that entropy sets in, because it's maintenance gets difficult for other programmers.

So I see it's about software entropy, that is a measure of how complex the maintenance gets when we add more code to a program, based on the methodology of Extreme Programming that have the characteristics of refactor code, simplicity in code, keeping design clean among others.

The author said design is not dead, but it had changed looking for: communication of the design through diagrams, keeping clear and simple code, refactoring and keeping an eye to the future to have in mind future problems.
So, from my point of view I agree with the author the design in NOT dead, but it is in constant grow, to get a better standard of design that helps when we code. As my experience with some other courses , design seems to be not useful, but at the moment of implementing, sometimes helped for reducing time and bugs, always if the style of design was good.

Madrid, Spain

For more information visit Is Design Dead?