HFOOAD Ch 8. “Originality is Overrated” Indeed…

--Originally published at S' Nami Bog. Servitas Vitae

One of the hardest parts of building or wanting to build an app/software is the design. Specially having lots of design principles to follow up and understand.

Thinking on building one on your own most likely will stress you out and you will not get somewhere, there is no point on breaking your head thinking about if your design is innovative enough to fulfill the expectations of someone else or even worst trying to innovate the OO. Time has proven that principles that have been implemented actually work and those are more flexible in terms of maintenance and the future possible extensions.

Here are some of the principles that could work for you and your software:

  1. Open-Closed Principle: Allows you to modify the code without erasing any line, just by adding. Of course in order to be elegible it must be open for an extension otherwise it won’t work. Also it must be closed for a modification.
  2. DRY or more commonly known as Do not repeat yourself: Is a principle that focus on avoiding duplicate code that could potentially be repeated. Mainly focuses on abstract things that are usually located in a single location.
  3.  LSP: Liskov Principle is mainly focus on the subtypes which must be able to be substituted for any given base type without breaking the code and its functions.
  4. SRP: We can relate this principle with two brothers. If the younger brother gets harmed the responsibility would be of the older brother. Same goes for the objects, this way we know which class would affect the other amd be responsible.

Mastery 11 – Verification and Validation

--Originally published at S' Nami Bog. Servitas Vitae

Throughout my time working with code, developing from zero and testing other’s code we all come to the conclusion that working code that actually compiles (yes I am pulling the typical and cliché meme) does not mean that it is ok for a valid use.

Let me explain, lets say that you are building a project that involves creating many files (10). Some of those files are linked to each other, using inheritance and when you finally want to test them you compile them one by one. Surprise? No compiling errors but guess what pal, none of those are actually linked to its entirety. Then you start to guess what are you doing wrong… I mean all of those compile! Where is the mistake?

Whenever we have those type of problems it is recommended to do the following:

  1. Calm down
  2. Verify
  3. Validate

In other words, the code MUST meet and fulfill the specifications. Obviously it also needs to do its purpose otherwise it is “useless”.

A clear example of a program that needs to reworked would be a calculator. It is very easy to build its UI, place the numbers and operations but whenever the input is written, for instance 5 + 5 the result would be 10 but if it gives you 25,m what is wrong? The tests were not done on its entirety and QOL (Quality of Life) modifications must take place.

It is important to understand that QOL involves doing verification and validation, which both may sound a like but are not.

Verification: The process of checking if the system is being built correctly in every single of its aspects such as the processes. The requirements are set but it does not mean that other aspects are being done correctly therefore a whole new direction is being Continue reading "Mastery 11 – Verification and Validation"

Mastery 12 – Testing in OO. How to properly test

--Originally published at S' Nami Bog. Servitas Vitae

Whenever we have a problem in our life it’s said that we can solve that problem with over 50 different options and still solve it.

This applies for testing code, the paradigms change how we approach and do the overhaul of the software.

Through the course and the blog posts we have discussed that anything that involves OO needs a different approach but why?

In anything that involves OO = Object that is and must be dealing with another object, think about it as a chain. Checking the output of a OO code is easy, you need to verify that everything is connected and the arguments are fulfilled otherwise it won’t work; nevertheless, when you check an object and a modify version is replaced the chain it created bust be checked as well.

In any case, if the chain of objects is not checked problems will arise and give trouble. As mentioned before the use of Object-Oriented has been the main “discussion” therefore using the concepts and key components is a must.

In this case, inheritance which is arguably one of the key components of good OO programming is in charge of ensuring that the parent object is well implemented and doing all of its functions. In case it is not well implemented the child class cannot inherit enough attributes and any methods that were implemented on the super class, therefore it won’t work properly.

Mastery 9 – Class to Code?

--Originally published at S' Nami Bog. Servitas Vitae

I’ve always believed that paying attention in class saves you up to 50% of the work done at home. Why? Just like anything in life if we dedicate enough time it is easy to do. Think about math, you learn how to add, subtract, multiply etc at school and because you attention was only focused on that you get the general idea, the true definition and the main question: Where does it come from?

If we take this to the next level it would be with code. The teacher in most cases uses the projector to display the code and explains not in its entirety but most of the lines of code plus the questions the students may have.

A personal experience is with Java and OOP, one of the main reasons of why most students bail and move to another degree (boooo!)

I took the class with a teacher that took the time to explain even the smallest things but it was up to us to explore the code, use and understand how it works. If you did not practice enough or use the learnt code in other scenarios then you were screwed.

Let’s imagine that classes are a big sandbox in which anything is validated, after that the sandbox becomes a true test with no trial and error. If you missed you missed.

I truly believe that dedicating at least 3 hours to a class that you take two days a week is the minimum to have an idea of how things worked and of course how things are linked.

 

HFOOAD Ch 7 – “Bringing Order to Chaos”

--Originally published at S' Nami Bog. Servitas Vitae

The amazing line of those start-up companies is always “Hey! Where do I start? ” or “Do you know where to start?!”

It has been this cliche thingy to ask that question that a lot of people get tired of it. Like, leave me alone! I know what I am doing. Yes, I did used a common used phrase by Kimi from F1.

e105d630c49adf1241aae6a9e7e8297db5752b87a489304802c485d65ffc7ed5

Maybe if we step back a little bit and relax we get to know where do we want to go. It is very easy to other people to comment about the stuff we should do or not do.

Grab the whole thing, be a goddamn man and split it. DO NOT try to eat the whole thing in one sitting, it is almost likely to be impossible. This is why this chapter is so damn important because it teaches you that splitting stuff is not always bad.

This ideology is best described and named by the book as Well-Ordered and Well-Designed Application. Picture this, you have a big cake of let’s say 10 slices, it can be divided up to 10 slices. Each slice is a different flavor… you will never taste the true satisfaction of eating the cake so what do you? Hmm… cut it? Maybe? I do not know.

OF COURSE

Start working (eating) one and whenever you finish it go for the next one. Do not rush it m8.

Another addition to this blog would be the famous 3-Q that are involved in the architecture.

Is it part of the essence of the system?

  • Is it part of the main core? If you remove it does it affect the program or not?

How can I do it?

Lisp, the Good news and most likely the Bad News

--Originally published at S' Nami Bog. Servitas Vitae

Throughout all my years at ITESM this has to be one of the very few essays I’ve read with passion of knowing more about it. I truly recommend it to anyone who has the desire of learning how the MIT and New Jersey operate.

There is a lot of information that could be part of this blog post but I think as mentioned before that the MIT and New Jersey are the most important topics of discussion.

MIT has always being of doing not the right thing but ‘what’s fair and square” and they showed it by using a consistent implementation. I also have to mention that consistent and complete implementation is what give its prestige. I mean, who does not want a simple interface?

Throughout the years we have seen some awful stuff but in time they implement new stuff and make it better. Like the song “started from the bottom now we here”, it is exactly the same thing for New Jersey, their ideology goes in that route. They (almost) identical to MIT tried to replicate the simple implementation as well the interface.

As we all know, the MIT is one if not the most prestigious university of the world. If getting admitted is difficult imagine the design they expect? Those are the major leagues, LISP is focused on that. They want consistent, good software and design. On the other side, New Jersey is backed up by C and Unix.

The “awful” implementation of New Jersey has seen the light many times in many ocassions. The long journey of updating and giving the proper service will always be welcomed even if the preview looked amazing.

I have to insist on this essay, they are right. There is a HUGE gap between software that is popular and the high Continue reading "Lisp, the Good news and most likely the Bad News"

UML Pt 2 – M #7

--Originally published at S' Nami Bog. Servitas Vitae

Have you ever wondered how time is relative and how a certain action can be done infinite amount of times? Something called State Diagrams are used for that.

State Diagrams are considered a behavioral diagram which helps to represent certain transitions of behavior. Throughout the readings we have learned that most of the time (if not all the time) software is never static but always dynamic, constantly changing in ways to help and improve our system that constantly changes a class.

In order to give a better approach to this whole diagram theme we will have to go deeper since there are two types of State Diagrams:

  1. Behavior Diagram:
  • Dynamic changes are always presented in software and this can be related to the commit done in over time. If we relate this with the commit done on Github are to reflect the modeling and of course the construction behind how the system works.

2. Structure Diagrams: 

  • It was mentioned before that most of the time software is dynamic and in very weird cases it is static; nevertheless, the way structure diagrams are used could be with an object diagram.

Whenever we are working with diagrams we can have up to two types of diagramas, the first one being component diagrams and the other one being package diagrams. Both may sound similar but they share its unique set of characteristics and are easy to differentiate.

Component

The Component diagram is normally used to execute a very stereotype function, this sounds like a cliché in software but it is the reality. Some examples would be the documents, files and of course the famous libraries that are 99% of the time executed. In order to have a good connection it is necessary to connect the components; nevertheless, in order to work “correctly” Continue reading "UML Pt 2 – M #7"

SimSE – A Sims on Java

--Originally published at S' Nami Bog. Servitas Vitae

What would you say if I told you that playing Sims (almost) using Java is possible?

I guess you would freak out. It is possible and it’s amazing, it’s free by the way.

The game consists on different characters who perform certain tasks and it is up to you to “regulate” their performance, the more points you make = more productivity.

The game also tries to mirrors how an office would work, if people do not get along with then productivity goes down.

As for how the game went for me… it was hard. I had to read the manual a couple of times to actually understand what the game wanted me to do.

Here is a photo of my final score:

Screen Shot 2019-03-25 at 6.25.42 PM

As for time elapsed, my score was of 1028 ticks.

Chapter 6 HFOOAD – Let’s be an Architect

--Originally published at S' Nami Bog. Servitas Vitae

Before reading this chapter I rewatched Inception, after reading the chapter I think there is a connection therefore you will see a lot of references to the movie connected with the chapter.

Ever wonder how can you do a work or maybe what are you going to work on exactly? This chapter says all about it. It is important for us to understand that in life sometimes we will do stuff without knowing if we like it or how are going to approach it.

If you have seen the movie Inception you will remember that the architect was the key to a successful “trick” because it is based on the “clients” memory, you sell it.

RespectfulBlackandwhiteGroundbeetle-size_restricted

giphy3.gif

This chapter is called “My Name is Art Vandelay… I am an Architect”. This chapter as mentioned before talks about being an architect to create stuff that others cannot, being creative and basically create the “impossible”. In Inception the architect has the knowledge of how buildings work and “science”, what Cobb wants Ariadne to do is put in practice the knowledge and take it to something BIGGER!

This chapter talks about to build bigger programs, bigger problems and of course know how to handle them. For this, we need to apply what Ariadne did… basic knowledge that was given from previous chapters. Here is a little “review” of the steps one must follow:

  1. Software is based on client’s requirements
  2. Software does what the client wants
  3. Create an easy changeable project if the whole thing needs changes

giphy

ANALYSIS

In Inception whenever they created the whole plan to insert the idea they went through a deep analysis of Fischer’s mind and what could they use to make it look more real. Same applies for a bigger system which requires a deep analysis. In order to create a

anigif_sub-buzz-15796-1534362901-1
giphy2
Continue reading "Chapter 6 HFOOAD – Let’s be an Architect"