--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”" →

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

USDP sounds like a shipping company but is not, sorry if your whole life has been a lie.

USDP stands for Unified Software Development Process but some people like to refer to it as Unified Process.

What exactly is USDP? Unified Software uses iteration methods which consists of having a base equation and constantly keep replacing the value with the obtained value until you reach the value or an approximation of what you want. It is also used for an increment in software development process and the most common and popularized example is the Rational Unified Process or RUP for short terms.

Many references would point out that USDP is not only about iterative method and keep doing it. Its based on a framework for a certain object, company or even an organization. It also shares and goes hand-by-hand with the RUP method since both work on a customizable framework. With those concepts in mind many claim that it is very hard to differentiate between them so sometimes are miscalled.

USDP v RUP 

One is owned and the other one not. IBM has the rights for RUP or a more technical concept… IBM has the so called trademarks. That is why USDP is usually used for a more generic way and are mostly used in concepts that need refinement; nevertheless, USDP first appearance was on a book named The Unified Software Development whose authors are Ivar Jacobson, James Rumbaugh and Grady Booch. Some may say that both of them have their own respective rights but it always comes down to personal preferences.

Characteristics:

USDP:

1. Iterative Process that looks for an approximation or result.
2.  It is always moving forward, in other words incremental.
3.  The more work the better. The core of the USDP is reflected by the team’s efforts.
4.  A Continue reading "Mastery 02 – USP, Knowledge is power!" →

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

First of all, teacher I would like to apologize for not attending to the past class, I will see you tomorrow.

On the first chapter I discussed and talked about how important it was to follow the requirements of a client’s client.

Even though that is important we also need to take into consideration that our client that is ordering the software also needs attention and dedication.

Most people work this way: What do you need?

I need a software that shows me the addition of this and this.

Say no more. What happens when you deliver the project? Well it is a different thing that the client didn’t want, then your boss makes a huge deal and you know the drill.

How can we avoid this and what went wrong?

Always ask your client what exactly does he want, why? Well, this will help you organizing your ideas and brain storm and deliver a product that the customer really wants. There are no wrong questions and you look more of a fool without asking and leaving with the doubt. Client wants it pink but you did it red. Easy task to fix it but the damage is done.

Another thing is to have into consideration that modt of the time the client will never be honest; therefore, we/you need to look deeper and understand them. Let’s say you are working for a company that sells clothes and their store has pink and red on the walls, customer says “I want it red” You must ask yourself if red is the only color he truly wants and if you have a doubt implement the pink one too. In other words be one step ahead and this doesn’t only apply with aesthetic things, you can also apply this to functions and Continue reading "Chapter 2 and something else" →

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

I wanted to know more about Software Development Life Cycle or shorten would be SDLC.

First of all I would like to mention that there are different phases, to be exact there are five and each one does a different function. I will do a breakdown of each one as followed.

Name of the phases:

Requirement Analysis, Design, Coding, Testing, Deployment & Maintenance

Disclaimer: All of this information is summarized from a video form YT whose will be referenced at the end of the post.

Let me start with Requirement Analysis:

As I mentioned on my previous blog the client needs to report what the customer needs or wants; therefore, providing requirements would be what the customer wants. For example, the customer would like to know if we have items in stock and if not an ETA for them.

I think we all know that whenever a big project is on the go a big team is also involved so it is no surprise that it needs someone who is an expert on analysis. This helps the project to be balanced in terms of logistics, financial support etc.