And then there was one…

This will be my final blog for this course, and all I can say is that I had a blast making these blogs. At my university, courses are usually very linear, and that can be tedious sometimes. You follow a certain path until you reach a goal, and you either pass or fail. In this course, things changed, and I really enjoyed that professor Bauer made us create this blog. Internet presence is a huge asset today, and I’m glad that I have some very good material on a bunch of software related topics, be sure to check them out!

All of that text above this is not really correlated to the topic, so sorry about that! Alright, today’s topic will be about the relationship between Agile development and Object-Oriented programming. Both are topics that I’ve covered before. Both have pros and cons. And both of them are very important to the industry and serve as a backbone to many systems and projects alike. So, are they somehow similar? Are these two movements correlated at all?

The answer of course, is yes!

First there was Object-Oriented programming, which started way back around the 60’s. OOP is a way of writing code that let’s us create easy to mantain code, while letting make big projects. It’s used by a lot of mainstream programming languages, and if you join any Computer Science degree, you’re very likely to encounter (and struggle with) OOP early on in your journey.

A young me during OOP class

Then we have the Agile movement. It is a bit younger than OOP, but it’s not young at all. Unlike OOP, Agile goes a bit further and attacks the way we do things in a project, not just code. I’ve said before that Agile methodologies are usually utopic in theory, yet hard to achieve in reality. But that doesn’t change the fact that it’s widely used in the industry, it really is a pilar of the software community.

The Agile life

So, why are they alike? Well, to start off, and I hate to be a negative Nancy, but both of these cool concepts are super easy to mess up. People use Java or C++ and think they are doing OOP, but we know that’s not actually the case. And there’s a bunch (like, literally everywhere) of development teams that use “Agile” methodologies, yet they’re just doing daily meetings and hoping everything works out for the best. Both OOP and Agile have huge world-wide conferences were people meet each other to talk about the current state of things in that area. OOPSLA is legendary, but I did some research on it and I guess it’s kind of defunct now? There is something called Splash which I think is the new equivalent of OOPSLA. The Agile conference just happened in August.

I have two main takeaways from comparing OOP to Agile. The first part is that both movements have a human element, and in an industry with so in need of that, they gather a massive amount of people that are interested in those two movements. What I mean by that is that they both feel like a community, and being a human is all about being part of different communities. Think about it. The people you go to work with are a community, same goes for your neighbors. Those guys you meet each Wednesday to play soccer with? That’s a community. A group of people that have one or several interests in the same stuff. And what are OOP and Agile? A community! So I think that’s an awesome part of the correlation between each other, and a massive part of why they have been succesful.

The second takeaway is that OOP happened first, and it wasn’t as deep as Agile. But the first people that used OOP eventually moved on in their careers and started managing instead of only creating code. So naturally, that was when Agile was born. It just makes a lot of sense. It’s almost like Agile is the next generation of OOP, but it’s obviously different from it. I just thought that was interesting, but I don’t know, maybe I went to deep myself.

I just wrote a lot of words. It’s really sad that this is my last blog for the course, but it won’t be my last blog. For the past 4-5 months, I’ve been working on setting my internet presence, and this blog will continue to be part of my strategy moving forward. So I hope the three people that read my stuff continue to be here with me!

The future is coming, and it’s going to be awesome.

Thank you for everything, professor Bauer. You rock.


Kent Beck had a video chat with my class

Yes, that Kent Beck. I’ve been very fortunate to have Ken Bauer as my professor this semester, and one of the cool things about him is he knows a bunch of cool people, including Kent Beck. So we had a very cool session with him, and it was one of the greatest experiences I’ve had in my student career. I just wanted to talk briefly about that, but let’s get on with the topic.

Simple things are often great things, and test-driven development does a lot of small things that inspire confidence. One of the first things I was taught in my Data Structures was how to solve certain problems using recursion, and one of the key giveaways that I got from that lecture was how recursion focused on splitting a big problem into smaller fragments, thus making the problem easier. TDD is similar in that we can use it to create massive systems and divide them into smaller tasks. By solving smaller tasks, which we call tests, our code usually is much cleaner than solving a chunk of stuff.

Split up, gang!

Keep it simple, stupid, is an awesome principle that is used in TDD, and I actually think it applies to a bunch of stuff in life, but I guess I’ll talk about that in another blog. Simplicity is elegant, and when you reach elegant solutions to big problems, life can be pretty good.

Another cool stuff about TDD is how code keeps improving all the time. There is literally a step for refactoring code that tells you exactly what to do to make your code more clean, more elegant. And in an industry where programmers are judged by how clean their code is, following the steps that TDD lays out is a great way to develop cleaner solutions.

Look, I could go on and on about all the great things about TDD. Heck, there’s even a whole benefits section in the Wikipedia for Test-driven development. That’s nuts! The influence that this way of doing development in the industry is huge, it’s everywhere, and it has a reason to be everywhere. When things are done right, it’s something incredible.

Just wanted to add this here for kicks

You can check out my work at

Testing, but it’s object oriented

Systems come in all shapes, colors and forms. Some are big, some are small, and each requires a different strategy when it comes to testing, so it shouldn’t be a surprise that object oriented testing is a bit different than your regular testing.

We’ve talked about object-oriented programming a bunch, we know what it is, and how popular it is, yet there is not a lot of material on testing for object oriented systems. The beauty of OO testing is that it can be divided into three different branches, and we will cover all of them.

The three stages of OO testing

Let’s start with class testing, because of course we will start with class testing. A class is a key component of OO, it is the blueprint of how we will build stuff, and a beautiful way to organize code. So when we do class testing, we are basically checking each of our classes for errors or bugs that may give us headaches down the line. It is the way to validate that our class is following the design we have, and it ensures that every little part of our class, wether that be an attribute, a method, or an interface, is 100% bug free.

Then we have inter-class testing, and it’s a bit more complex than class testing. Your classes may be bug free when tested individually, but OO is all about interaction between classes and modules, so now you have to verify that all is well when the classes in a system are working together. Our system should be integrate, and inter-class testing is used to verify integrity.

Finally, we have system testing. At this point in our testing, we should have an integrate system, since we’ve already passed the inter-class testing. Now is the time to check upon the system’s compliance with the specified requirements that were defined in the analysis phase. Black Box testing is generally used to validate our tests during this stage.

As you can see, that’s a lot of testing! And I’m kind of tired of using the word testing, so that’s the last you will hear from it, ha.

It happens…

Be sure to check out my website at

Valid validation and verified verification

Hi there. During this wonderful 5 month journey, we’ve talked about software a lot, and we’ve mostly talked about how software is created. The industry expects certain things when creating new systems, and there is a whole process of normalization that exists out there. We’ve talked Analysis, Design, Implementation, but we’ve yet to talk about Verification and Validation, another key element of this beautiful process that we call building software.

It’s super common for any industry to have some sort of validation on products and services that are created. For example, the ISO 9001 is a quality control standard that many companies use to manage quality and show the world that their product is worthy. So my first action when doing research on this topic was to look for the different standards out there, yet my first google search didn’t yield exactly what I was looking for, so I just turned to the Software verification and validation page on Wikipedia, which actually has a decent structure on the topic.

Not this type of validation, but a meme is a meme

I wanted to talk about the difference between verification and validation, because apparently they are not the same! We use validation when we are the end of a development cycle, or when we are “finished” with the system. You can use it to validate that all the user requirements are fulfilled and that the system is full go. Verification is a bit more complex in that it handles the output of individual phases during the development cycle, so you use it to ensure that things are going the way that they are supposed to. Both are super helpful, yet I believe that verification can sometimes be biased depending on who is actually doing the verification.

Regarding the standards that I found, the first one is the ISVV, which stands for Independent Software Verification and Validation. It is aimed towards safety critical systems, and you can see that doing correct verification and validation in systems where potential lives are there for the taking is something really important. There is a reason that you do take an Ethics class during your degree. The cool thing about the ISVV is that their tests are done by independent engineers, so there is no bias going on during the process.

I tried searching for some other standards, but I didn’t find anything too specific, except for the fact that the FDA requires some form of verification and validation as well.

That’s going to be it for this blog, hope you enjoyed it, more blogs are on the way!

Be sure to check out my website at

Code revision can be tough, but it makes us better developers

One of the coolest things about programming is that you can find many different solutions to a single problem, each with their own different approaches and styles. However, in a world that is hungry for speed, a world full of different problems and different situations, we are taught very early in our careers that some solutions are better than others.

Consider this. If you wanted to sort the numbers in an array from the smallest, to the biggest, what solutions can you come up with? It’s one of the first problems we are taught in our Data Structures courses, and we know that it can be solved in a lot of ways. The first that comes to mind is MergeSort, which uses recursion to solve the problem, and has an O(n log n) complexity. There is, of course, BubbleSort, which has an O(n^2) complexity. And I could go on and on, with many different solutions, yet it’s clear that there is a better solution available, and that’s the one that we want.

Quick representation of BubbleSort


So after all of that text, I haven’t even started to talk about code revision. For some, code revision is a thing of nightmares. It is not commonly talked about, but our code is somewhat part of our ego. It is a reflection of how our brain thinks, and some people are scared of what others might think of their ways. No one likes being wrong, and if my code works, why should anyone else take a look at it? Well… You might believe that your code works, but no one is perfect, and everyone makes mistakes once in a while.

Humans are often victims of what is called confirmation bias. In his book, “The undoing Project”, author Michael Lewis, talks about this behavior that can conquer our rationality. Think about it, if you’ve been trying to solve a problem for a while, and you test it once, twice, it worked, you are very likely to convince yourself that you’ve reached the perfect answer. After all those hours of work, how could your answer be imperfect? Yet, it is very easy for that answer to be incorrect, and that’s why code revision is super important.

confirmation bias


If you want your code to be good, you need another pair of eyes, and another brain, to look right through your code. It can be tough to be judged, but it makes you better. Tough love.

And while code revision sounds great, and we should all do it, that doesn’t mean that it’s always the best. For example, someone could feel superior to you and make you change your code even though it’s not wrong. Code revision needs that all the people involved have an open mind, and that is something that is often lacking within teams. Everyone needs to be on the same page, but there are often egos to be fed, which makes the process of code revision a tough task.


You can check out some of my latest work on my website:

State diagrams and user behavior.

Excuse me for such a boring title, but I couldn’t really come up with anything better. Last blog post, I talked briefly about how we use UML for a lot of things that make the organization easier in the software industry.  However, that was just meant to be a very brief introduction, and now I will talk about three different types of diagrams, just as it’s described in the title.

Let’s start off with state diagrams. It is used to describe the behavior that a system will have when it is presented with certain parameters. It basically gives us an idea of how our system will behave when it is presented with certain situations. I will leave a very basic example of a state diagram that represents user verification in an ATM.

Source: GeeksForGeeks


This particular state diagram was created using UML notation. For example, we can easily recognize that the simple black dot is a representation of where a situation starts. The user, in this case, will swipe his card, and the system will ask for a PIN to secure that the card belongs to him. If the PIN is not correct, the system will stall until it is correct. Since this is a simple example, it acts like if it would let you test an infinite number of PINs, but we all know that an ATM usually has a security system in place to stop sketchy behavior. However, if the PIN turns out correct, then the user is identified and it can move on to another process. See how that diagram only describes one part of the ATM? That’s because state diagrams can be used to describe either a whole system or represent smaller parts of a big system, which makes it more organized.

Why is any of this important? Well, it’s very easy to see in action. We always have ideas of what we want our system to be, but users don’t always see it that way, and they can behave in different manners, such that, our systems must be prepared to respond well to them. For example, if we have a simple calculator that can do addition, subtraction, multiplication, and division, what could go wrong? Well, a very easy way to make the whole system go kaboom would be to do a division by zero, which should create an exception, and therefore, the system would crash. But if we have a clear-cut state diagram, we can very easily predict this behavior and have our system react in a positive manner. After all, nobody likes it when their program crashes. State diagrams are our friends.



That will be all for this blog. Until next time!


You can check out some of my latest work on my website:

We use UML a lot.

As a Computer Science student, I’ve seen UML pretty much in every single course that I’ve taken. The first time I ever saw it was way back in my Object-Oriented Programming course, where I saw it in effect when we were discussing classes in Java.

But as you probably already know, UML is used for a bunch of cool stuff, and it’s mostly used by software engineers. The main purpose of UML is to provide a visual of how a system is designed. Visuals are great, and when we are dealing with software, systems can become very complex, very fast. Enter UML, the standard in the industry for the visual representation of a system. UML is simple to understand, and that’s why I believe it is very popular and used heavily.


I’ve come to appreciate that where chaos can be born, the software industry usually has an answer to contain that chaos. We all have ideas, we all want to create awesome projects, but going from an idea to a whole system is borderline impossible without the use of a tool like UML. Organization is key! And in order to create wonderful systems, we need to be as organized and clean as possible.

You can also see that UML is tied closely to most of the topics that we’ve discussed in this blog before. Use cases, design patterns, modeling languages, heck, it’s even a big part of the design phase that is used quite a bit in life cycles. UML is everywhere, and that’s a good thing.

This blog will serve as a brief introduction into UML, and I will make a sequel to this post very soon! Stay tuned!


You can check out some of my latest work on my website:


Patterns are everywhere

One. Two. Three. Can you guess what comes next? If you answered with four, then you have made the correct answer and you’ve discovered a pattern in those numbers. We call something a pattern when we discover a behavior of repetition. Design patterns are, patterns, but used to find common ways of solving software engineering problems.

Hi there. It’s been a while since I’ve been able to write cool stuff on here, so I’m very glad that partial exams are mostly done for and I can write again. I’m way behind on all of these blog posts, but I do promise I will do my best explaining some very cool topics. Anyhow, here we go again.

Design patterns are pre-established ways of getting to a solution when working on a software project. You can think of design patterns as sort of a blueprint to produce a certain result. However, sometimes they are confused with algorithms and they just are not the same thing. Within what I’ve experienced with design patterns in my young development career, they are more than anything a way to structure code in order to create a clean and balanced solution.

I only have experience with one of the many different design patterns that are out there: the MVC, also referred to as the Model-View-Controller design pattern.

Courtesy of the brilliant folks at the London App Brewery

The photo above is a very basic way of explaining this design pattern. When we go to a restaurant, we sit down, look at the menu, and we decide what we want to order. In order to get there however, we need to ask our waiter to get whatever we want from the kitchen. The waiter then goes ahead and tells the chef what we ordered, the chef prepares our meal, hands it out to the waiter, who then brings it out for us to eat. The food that we have received is what we consider to be the view of our program. A more literal way of thinking about this is the user interface that we usually have when we use a mobile app. Then there is the waiter, who in this case is acting as the controller. The controller’s job is to communicate within the model and the view. Finally, we have the chef, who we consider to be the model. The model is in charge of using whatever resources it has at hand, and handing out the controller whatever the view asked for.

So that’s a very barebones explanation of what the MVC design pattern is. You can easily see that it can be used mostly with applications, and it works rather well. However, the MVC pattern might fail in other areas of software development, but that’s perfectly fine, because we have a boatload of other patterns we can use. Also worth mentioning that design patterns aren’t quite perfect. They do have flaws, and the community can tell you all about them. I mostly used the following link to find a great deal about patterns, so you can check it out. Also, if you’re interested in mobile development, the picture above is taken from an Android development course on Udemy, which you can find here.

Here, have a meme on the subject, on the house

You can check out some of my latest work on my website:



My web development journey and a cool little thing called Vue…

I promised myself that I would use this blog not only to do the classwork that I’m required to complete, but also as a way of talking about my life and my work. This is the first of what I hope will be many posts about little snippets of my life, what I’m doing, what I like, etc. Not everything has to be about school, and I’m glad I can use this blog to express myself. Anyhow, here we go.

I’ve been doing web development for quite a while now. You could say I started back in High School when I would sell some HTML templates to my colleagues so they could turn it in as their own and get a good grade in our computation class. Not really proud of it, but still, everyone has to start somewhere. Everyone thought I was a genius, ha. I was really the only one that was into programming and IT in general, so when I showed people some of the very basic stuff I made, they were impressed. Those were the days!

I quickly engulfed myself into HTML and CSS, and I was very proud of the cool websites that I was creating, yet I was a programming noob, and I really didn’t know anything about Javascript or PHP. So I was basically just creating static websites that implemented good UX principles. I started to get really good when I took this course on Udemy made by Jonas Schmedtmann, which I will link right here if you’re interested in it.

Then I kind of stalled my skillset for a while. I knew I could create websites with great design principles, but I thought that was the end of the road, that there was nothing more to learn. Wow, I was so wrong, there is always something new to learn, and once I got to college, I started unveiling all the cool things you could do when you linked HTML and CSS to Javascript. JS is great, but it has it’s own faults, so that’s when I was introduced to many of the frameworks that exist out there. React, Angular, and of course, Vue. Great! Which one should I learn?, was my first question. It was almost like going back 3 years and deciding between Python, Java, C++, etc. I believe anyone involved in the tech industry has faced this type of crossroad, and it simply sucks.

It was then that I got a project offer to develop a web application for a company that gives out loans. My team and I consulted with different people in the industry, and most agreed that Vue was best suited for the task ahead. I believe the best way of learning something is by building something, so it really could not have been a better opportunity for me, a guy that really wants to get into the web development world, and I know that you should at least know one of the three frameworks I mentioned earlier.

So I started to scramble for resources to learn Vue. I first went looking at, which, in my opinion, is one of the best websites if you’re into programming and else. I found a free 3 hour tutorial that promised me to learn the basics of Vue, yet I really only watched about a half hour of that and found myself kind of lost. Yet, in my rally to learn this framework, I took myself to Youtube and found a channel that I had already watched videos of: Traversy Media. Traversy Media is run by Brad, who I’ve found to be really helpful when learning about web development. He’s an awesome dude with a great attitude, and I’ve just really enjoyed watching his tutorials. He made a little series based on Vue and Firebase, and after about a day and a half, I learned about some of the basics of Vue.

Vue is unlike any technology I’ve used so far in my young career. I’m just barely starting, and I still consider myself a Vue noob, but I know that it has great potential, and I look forward to working with it for a long time. Everything seems to be so straightforward, from the router, to the directives, etc. It’s been a blast to learn all of this, and I look forward to getting better and better with Vue with the passing of time.

I’ll keep posting stuff on my development in Vue, and I hope that you’ve enjoyed this blog post. It was kind of long, but you have to start somewhere. If you’ve made it this far, you deserve a gift, and your gift is the following:

You can find some of my latest work on my website:


Models are cool, deal with it

When we talk about pretty much anything in life, we can usually find a model to help us represent the concept and core of that something. For example, any equation that we find in the different science fields, such as Math, Physics, Chemistry, etc. is a model of a situation. Maps are used daily to help us have a good understanding of how a city, a country, a continent, the solar system, etc. looks and behaves. Models are all around us, so it’s no different when we talk about software, and there are so many different modeling languages and tools that we can use, most of them for free!

I feel like there are so many different modeling languages out there, yet the one that any person who has had any sort of education in software engineering is UML. I believe I’ve already seen it used in about 4-5 different courses that I’ve gone through in my 2 years at my school. I first saw it in second semester when I was suffering through my Object Oriented Programming course. Objects can be hard to explain, yet UML is so simple that I believe anybody could understand an object just by looking at a (very key) good UML diagram of said object. I also used it in my Databases course when we were describing relationships between entities in a database.

Many of us are very lazy and want to just code our ideas away. Yet, when we get into trouble and can’t seem to figure out why, we notice that our project lacks complete organization, and is just a bunch of spaghetti code. UML helps us make our life easier, and I can say for a fact that I will be using it in a project very soon, as I want this project to be really organized, and I feel like I need a good representation of it all. That’s what UML is all about: good, clean representation of a system, and it is very valuable to everyone.

For tools to model my systems, I use Lucidchart. There is just a huge array of different tools that have the resources needed for models, yet Lucidchart is free, has an amazing amount of resources that not only includes stuff for UML, but for other modeling languages. It has pre-made frameworks of some very common cases, and it can connect to Google Drive, which is a big plus when you’re working with a team. I’ll leave the link to Lucidchart right here, I really recommend it.

You can check out some of my latest work on my website: