Posts

Showing posts from March, 2019

Ethical Reflection on Ready Player One

Hi, today’s entry (and maybe the last one) is going to be a little different. It will be an ethical reflection about the course’s book called “Ready Player One” by Ernest Cline.    This novel is about Wade Watts at some moment in the future with a complicated world situation. OASIS was developed by a programmer called James Halliday. Basically, any person could distract himself from the real world and hide or spend time inside this virtual one. This sounds like a normal game but it isn’t. Oasis included everything a person can do in the real world, from working and studying to practice hobbies and buying stuff, it is literally the same as the real world. Suddenly, James Halliday died but left a competition to win the whole control of his fortune, company, and Oasis. Obviously, Wade wins. I want to mention that this book was pretty interesting for me and I think I can say it was one of the most entertaining and funny lectures I've ever had. This just because I’m really exc

An Introduction to Metaprogramming

Hi, today's entry is going to talk about an article called “An Introduction to Metaprogramming” written by our professor Ariel Ortiz in 2007. First of all, I just want to mention that I’m really impressed because I didn’t know that our professor had many published articles and papers (we saw the others in my other blog for Compilers Design course). Basically, as its name says, it talks about metaprogramming, which is defined during the article as a program that generates other programs or just program parts. It is used to eliminate or just reduce a “tedious” programming task. It is like instead of writing complex machine code programs, we use any high-level language and use the compiler of that language to do the translation into the programs equivalent in machine code (low-level language). I have to admit that before reading this paper, I hadn’t fully understood the metaprogramming meaning and importance. We used and applied that term in a past course called Programming Languages

Microservices

Hi, today’s entry is going to talk about an article written by James Lewis and Martin Fowler called “Microservices” in 2014. Basically, by calling microservices, they are referring to like a particular way of designing software applications as suites of independently deployable services. But something interesting is that there is not a precise definition of that type of architectural style, there are only common characteristics around distinct organizations, business capability, automated deployment, intelligence in endpoints and also decentralized control of languages and data. This was the first time I heard this term, and something strange is that despite I didn’t notice about its existence I’d used them sometimes. Later in the articles, the authors gave us some characteristics that any Microservice Architecture must have. They are the following: 1.       Componentization via Services:  This is telling us that by building software, we put together components. So, this archite

The 4+1 View Model

Hi, today’s blog entry is going to talk about 2 videos and one article called The Elephant and the Blind Programmers, by Grady Booch.  The first video was about de 4+1 view, while the was more related to the article as both explains the Elephant and blind programmers’ case. In the case of the 4+1 view, there are five main aspects to consider: 1.      Logical view:  It’s the logical software’s design and what components will be made and how the should behave. Class diagram. 2.      Development view:  It’s concerned with the organization during development and the interaction between the program and its components. Component diagram. 3.      Process view:  Activity Diagram, it includes de concurrency and synchronized aspects, and also how the program functions. 4.      Physical view:  It’s how the software and hardware are related and their interaction, how the system looks like when finished. Deployment diagram. 5.      Use Case view:  It’s how the system interacts with

Understanding the SOLID Principles

Hi, this entry is going to talk about a section called “Understanding the SOLID principles” from the book “Ace the Programming Interview: 160 Questions and Answers for Success” by Wiley in 2013. Basically, the acronym SOLID is explained a round this book section. This acronym stands for five accepted principles about object-oriented programming and design: 1.       S ingle Responsibility Principle: It stays that a class should have just one responsibility. Despite the fact that this principle sounds easy, I found it a little bit complicated, because the explanation wasn’t direct and simplified. Also, the author mentioned that there might be cases in which a class might have two responsibilities. So, at the end, what exactly does this principle stands for? 2.       O pen/Closed Principle: It stays that a class or a function should be open for extension but closed for modification. What does this mean? Our code must have the capability of being extended, but we have to always