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.

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.

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.

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.

You can check out my work at grupoargon.co

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.

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.

Be sure to check out my website at grupoargon.co

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 grupoargon.co

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.

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.

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: grupoargon.co

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.

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: grupoargon.co

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: grupoargon.co

Peace!

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: grupoargon.co

Peace!

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: grupoargon.co

Peace!

Use cases make things easy

I think we (the software engineering industry) can all speak from experience that it can be hard to explain some of our own ideas to other people. We’ve all had that killer app idea that had the potential to become as big as Facebook or Google, yet we find ourselves at a crossroads when trying to explain the functionality of it to our peers and friends. Yet, in 1992, our good pal, Ivar Jacobson, introduced the idea of use cases to help everybody explain what the heck is going on in any system.

Use cases can be used for many different fields, yet it is widely used in the software industry, and it was one of the main components of the Unified Software Process. When describing the definition of a use case, we need to understand the different parts that can interact with each other in our diagram. The first one, and I believe the easiest to understand, is the system part. A system can be a lot of things, it could be a web app, a mobile app, a business process, a logistics solution, etc.

The next part of a use case, is the actor. Actors don’t have to be human, they just have to use the system in our diagram. This can be a little tricky, because it’s not always clear who interacts with the system and who doesn’t, so it’s key to have that established to avoid errors. An actor can be labeled as primary or secondary, the difference lies within how the actor “acts”. A primary actor will initiate the system, so for example, any user that uses an app is considered primary. Secondary actors react to what the primary actor is doing, and in our diagram, they are shown to the right of the system, while primary actors go to the start, or left part.

The third part of use cases is, well, they’re called use cases, which is a little redundant, but they are basically actions that our system makes to solve any given task. So for example, a weather app gives you the ability to check the weather depending on any given city. That is considered to be a use case. They’re the functionality within our system that makes our system useful to the user. You want to be very especific with your use cases, and want to place them in the logical order that one would typically follow.

Finally, we have relationships, which, as one might guess, define who interacts with who within our system. This final part is very important, as it gives sense to our system, and will make our idea very clear. Relationships usually go from an actor to a use case and vice versa.

So there you have it. Use cases are a very cool concept, and a very useful one when developing any system. They provide clarity when it can be hard to explain using just words, and defines the boundaries of a project and the relation it has within itself. I wanted to mention that I made this blog based on Lucidchart’s video on Youtube about use cases, which was very clean and easy to understand, so I will leave that link in here.

Main Image by Bethany Drouin from Pixabay

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

Peace!