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

UML stands for Unified Modeling Language, it is considered by many a standard language (no wonder why we use it in almost every programming class). It is mainly to have an overall view of what one is working with. Moreover, it also works to start making a documentation, this could apply to database since building a UML based on DB is to store data etc.

UML was created by the OMG. Yes, the OMG which means Object Management Group. UML didn’t saw the light until its 1.0 version came out in 1997. One thing to have into consideration is that although you work with programming UML shouldn’t be compared with python or anything related with programming (actual code).

You could use UML as a starting point. Making a UML for a clock that divides the subclasses and its components such as elements,  behavior etc.

As mentioned before UML is mainly used for modeling and building the “end” product. See it as a blueprint that are used to build dry vans, houses and buildings. Some would even consider it a starting point and move from there. One thing people need to understand is that UML can be used for many things, not only programming. Take for instance a Zoo, you can classify the animals by reptiles, mammals etc. bigger classes that take a larger range of information.

What’s the verdict?

UML is used to create a starting point. It’s great to have a greater idea of what you are building and what you need to work with. In any case, not having all the elements is normal since UML also helps you to see what are you missing, what can you take out or modify. As history keeps moving more programming languages raised and it needs to be worked with Continue reading "UML Part 1 – MS #6" →

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

I’ve always think that the less clicks you need to do in order to get what/where you want means a great design but whenever you have to pay for it it’s click upon click upon click.

Anyways, that’s just a personal opinion. What’s Flexible Software? Is it good design? Less clicks? Great GUI?

Chapter five gives us a deep reading on what this truly means. As you make progress with your software it becomes harder and harder to keep up with the client requirements and need; nevertheless, any software is subject to change. Giving maintenance and constantly modifying the files is extremely normal but throughout my life I’ve seen two types of so called “patches”.  Some AAA Companies that make video games release updates every month or so and the player base has to wait and struggle with those bugs until they fix it. On the other hand we have Epic Games, creator of Fortnite. Those guys release a weekly patch to fix bugs, stability improvements and overall QOL updates for the game across all platforms.

I think Epic Games is the best example to use with this since they’ve divided their classes such as weapons, buildings, vehicles etc. Ch 5 talks about generalizing objects then make super class, for instance weapons instead of assault rifles, snipers, SMGs etc. Once accessed you will break down the super class in smaller classes and so on.

Couple of bullet points to have into consideration whenever making this type of strategy.

• Must be abstract class
• Implement placeholders
• Implement the actual objects, in this case weapons.

 

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

Ever heard about blueprints, brainstorming or templates? If so you do know then that all of those are related on giving an idea, concept and a starting point of something.

We usually use those to make a starting point whenever we are going to code and believe it or not, drawing actually helps you out too.

Here are some examples:

Object Pool

Any expensive acquisition is avoided and the resources will always be released thanks to the replying of the objects that are no longer used

Abstract Factory:

Instance of family classes.

Builder

Separates object construction that is attached to the representation

Factory Method

Instance is created of several classes

Singleton

Class what has one and only one instance that can/will exist.

DESING BASED ON THE STRUCTURAL PATTERNS

Object and Class are based and are the fundamentals of this design type.

• Adapter
• Bridge
• Composite
• Decorator
• Facade
• Flyweight
• Private Class Data
• Proxy

BEHAVIORAL DESIGN PATTERS

It is oriented to the class objects and of course to the communication between them.

 

 

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

People are so focused on their code and program/app that they forget about other stuff.

In this chapter it’s all about whether or not you should publish your app or if it is ready to be delivered to the customer/client.

It has to go beyond the code because the code is not the only thing that matters, you need to LEARN how to SELL your app and convince investors, clients and customers that your product can actually do a purpose in society and of course for the greater good.

Why is it important to actually learn how to sell your product and app? They (investors) don’t give a damn if you had 100s during your university days, all they care is about money, money and money. That’s why they look always for two things:

1. You know the basics.
2. You know how to talk and sell yourself.

Imagine convincing a table full of investors that have their accounts working at Wall-street and they say “You know what, you are in.” that has to be the greatest feeling ever but is it?

Let’s portrait this, a nerd guy creates something that could end humanity’s worst nightmare and that is dying from starvation. He goes and presents it but he doesn’t sell it. Why? Maybe his/her app does what he/she said but the convinced investors were not there and they won’t comeback for another chance.

Learning how to talk is as important to know how to write, implement and execute code. If you don’t know how to talk and convince other people that YOUR product is the right choice… then you are wasting your time and their time.

 

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

Software constantly changes.

That’s why sometimes reading books that were published years ago are not that good unless they are from software that hasn’t been updated in years.

This book was written by Eric S. Raymond and its title is The Cathedral and The Bazaar written in the year 1999.

One would say, if this book is about technology and you said technology moves fast then why are you writing about this? Well, this book is oriented to the so called open-source development which is very popular nowadays with platforms like Github etc.

The book talks about the two ways someone can create software. Open and closed source. We have examples for open source like Python and PHP. For closed source software we have apps like Uber, Facebook and Twitter. The main difference is that open source is for people to help and contribute by fixing and finding bugs but it still can be dangerous. Closed is just closed, no one can see it.

What I mentioned before is from my opinion but in this book he describes it as a cathedral development model because they close it to people in a certain time while a Bazaar is more of a “hey! come here! grab everything you want.

Think about the Basilica de Zapopan or any other major temple in Mexico. Sure people can come in, do their activities but after 10:00 PM is bye bye, thanks for participating but we are closing. Of course closed.software doesn’t actually close for a certain amount of time but I think this analogy works.

As for the Bazaar, we have multiple examples here and why this can relate to software. Every Friday they set up the placement and they sell lots of stuff.

There was a time when the government (developer) decided Continue reading "The Cathedral and The Bazaar" →

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

This chapter talks about one of the most important things a programmer/developer must face whenever he’s working on something “important”. Everything is important right?

This chapter highlights the fact that delivering and publishing software are “technically” same but different at the same time.

1. Publishing: Whenever you publish something there are two scenarios. Is it BETA or Closed-BETA?
2. Delivering: Does your software fulfill the expectations of the client? Does it actually do what’s supposed to do?

Those are some of the questions you might have whenever two of those things are about to happen.

We are all humans and we tend to do mistakes (a lot of them whenever we are involved with technology) but whenever you launch something to the internet expect backlash… and A LOT. IT’S DAILY! Patch after patch you’ll try to improve your work and even though you fix something you will break something, that’s how it is.

To avoid certain backlash you should focus on making a learning curve, is it hard? Does it actually take a lot of time? That’s why you go for the user case and learn from scratch what does it feel for someone to use the software.

First of all identify the problem and of course be nice and endure the mean comments people might say about your software but once you understand what the problem is you can just remove it or fix it.

By doing this you can and will help newcomers and long time users happy. All the time try to focus on the mean so you help 50:50 of the users.

 

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

You may say that those are are related or maybe you even say those are the same things.

Both are a methodology that technically are a must while building apps and projects that require employees to use the app. It helps to organize and divide by parts what the app should do for a specific user and then go from there. Even though they are technically the same a Use Case is specifically oriented to a user DOING/EXECUTING the action and step by step.

While it gives the user an idea of what it might do it has to be grouped by certain elements that are used together to create a perfect interaction between machine and user. For instance, if the user is an administrator the system should and must contain ALL activities related to this action. How? Well, being able to see pricing, money and customers and then be able to work from there.

Here are some of the possible and most common characteristics:

”

• Organizes functional requirements
• Models the goals of system/actor (user) interactions
• Records paths (called scenarios) from trigger events to goals
• Describes one main flow of events (also called a basic course of action), and possibly other ones, called exceptional flows of events (also called alternate courses of action)
• Is multi-level, so that one use case can use the functionality of another one.”

 

References:

Margaret Rouse. (n.d). What is use Case?. February 22, 2019, de TechTarget Sitio web: https://searchsoftwarequality.techtarget.com/definition/use-case

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

Chapter three is all about a relation between human beings and our desire of getting more… and more.

Let’s say that you hate something and no matter what they do to please you the hate is still there. Time passes and things have changed; for some odd reason you go back to read about it, for your surprise you read and genuinely enjoyed it.

The phrase “I love you, you’re perfect… now change.” is something related to our everyday lives. As we grow up we want people and things to change, obviously for the greater good and this goes hand-by-hand with developing software.

Even if their code, your code or my code works and does what we EXPECT it to do we always want to have per se having a neat and clean code. No bugs whatsoever etc. Same applies to the clients. They have something that is working and they always want change.

Now, I had some doubts about whether this made sense or not because we’ve heard multiple times throughout our lives the phrase “If it ain’t broken don’t fix it.” but this doesn’t make sense!

Do you remember Blockbuster? Do you remember the mailing companies? Do you remember going to a specific store at a specific place at a specific time just to get something you truly wanted? What about the taxis throughout the world?

All of those examples that are involved in questioning if you remember them said bye bye thanks to software. Yes, software. This is why we go back to “I love you, you’re perfect… now change.” phrase.

Those companies died because while being perfect they never went through change! Taxi went to Uber. Stores went to Amazon. Blockbuster to Netflix and so on. We the consumer/client wanted change but Continue reading "HFOOAD Ch 3 – You must “Embrace Change”" →