Posts

Showing posts from March, 2019

Ready Player One

Ready Player One  After finishing Ready Player One, I must admit I really liked the book, way more than I expected to be honest. It made my geeky side quite happy and constantly bugged my anxiety and curiosity as I read through it. Now, taking on the book though an ethical point of view, I want to start by analyzing the following quotes: 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

An Introduction to Metaprogramming

An Introduction to Metaprogramming  In his article "An Introduction to Metaprogramming", master Ariel Ortiz explains the concept of metaprogramming, its several uses, and different ways to apply it depending the context of the problem to solve.  As the prefix meta suggests, metaprogramming refers to the practice of writing code for a program that writes code for a program. Kind of confusing, but that's the essence of it. They are use to automatize code writing and agilizing software development, as they are faster than writing the code by hand. Most of them are found in Linux platforms, and are usually composed of compilers, interpreters, parser generators, assemblers and preprocessors. After explaining this concepts, the author gives differents examples of metaprogramming by creating working code of C in Ruby, and viceversa, and proceeded to explain different elements that are very common in metaprogramming and easily implemented. First, he talks about eval, a

Microservices

Microservices In their article called "Microservices", James Lewis and Martin Fowler talk about the new trending and future of the design and architecture of software: The microservices architecture. In a general panorama, instead of having one big monolithic application, one must create several different small applications that coordinate with each other and create the bigger perspective for the entire system.This grants flexibility in the entire structure because changes are less expensive, as instead of rebooting the entire system each time there's a change in the requirements, one can just look into the specific microservice that needs to be changed and do it.    The biggest challenge to tackle in order to begin the implementation of this structure, however, is to manage the synchronous processes, and therefore, create a reliable controller that administrates and instructs the different modules that conform each of the microservices. However, I think it's pr

The 4+1 View Model

The 4+1 View Model After watching the video Six Blind Men and reading the article "The Elephant and the Blind Programmers", it can be obvious that developers oftenly struggle when deciding what is the problem to tackle and what is the optimal solution to it. People can be very certain that their solution and their view of the problem is the only one and the correct one, when it is possible that maybe non of them have the reason, and therefore they are all wrong about the problem and its solution. However, I can also see that, as in the story of the blinds, sometimes your perspective is limited to your area of knowledge. I think that you have to constantly try different abilities inside the programming area for you to have a bigger and more complete image of the whole problem, so you can propose more than one way to solve it, rather than specializing in one techinque and trying to solve everything with that one exclusive skill or strategy. There was another article that t

Understanding the SOLID Principles

Understanding the SOLID Principles In a section on the book “Ace the Programming Interview: 160 Questions and Answers for Success”, Edward Guiness talks about a set of practices to have simple and efficient code: The SOLID Principles. The acronym stands for:  Single Responsibility Principle Open/Closed Principle Liskov Substitution Principle Interface Segregation Principle Dependency Inversion Principle The Single Responsibility Principle (SRP) states that each class should have one and exactly one responsibility. Only experience and practice will help you determine what one responsibility envolves, The Open/Closed Principle (OCP) says that each class should be open for extension, but closed for modification. When adding new behavior, we should leave the base class alone and instead create new inheriting classes, and avoid unexpected consequences for the original subclasses. The Liskov Substitution Principle (LSP) says that the less inheritance we have in our cod