The Digital Wolf Space

On my last work we experienced our data Centre electricity cut because of a huracain and all paid operations of our clients went down and not functional.  After a meeting with the CIO we decide experience the cloud and reestablish the services we could there, we used to believe those services were expensive enough and could become something we won't be able to afford but after we start configuring and seeing the services and prices at cloud we realized we were wrong and change of mind and start thinking more seriously about cloud and the positives impacts it could have on a company. For us it was a big surprise realize that complex servers configuration can be done by any child on minutes and the overall speed of ours application becomes better than before, the cloud also gave us some tips to make our applications more efficient because tech us the important of maximize the use of the resources and reduces the irrelevant request that stress the resources and affect the overall pe...

The design patterns are repeatable solutions for commons problem occurring in software design, in this occasion we are going to talk about the  Chain Of Responsibility and Builder . Chain Of Responsibility The motivation: This pattern aims on the problem we face at software design when we have several requests and needs to be handling by different object depending on the type of information requested, that turn in plenty of references and instances on the program to make things possible.  Imagine a candy's coin machine, it doesn't matter what kind of coin you insert inside the slot because it has a chamber or chain of responsibility that check the coins and handle the task must be done by two options, return the coin or the candy, that the same the chain of responsibility do, it handles the request from the client and keep passing through the chain until an object inside could handle it. Here the diagram of the implementation: In order to expla...

The Dependency Inversion Principle is one of the five Solid Principles, this one state about making class dependent of abstraction instead of concrete object thus we obtain isolated and low coupling modules and low-level implementation details. The first time I heard about the Dependency Inversion Principle I used to confused it with the Dependency Injection Design Pattern but I was wrong because they are not the same although has relations each other. Since the Dependency Inversion is how we call the act of a class depending from an abstraction, the Dependency Injection instead is a design pattern where by object X is supplied the dependency of another object B. There are two ways of doing the dependency Injection, by constructors or Setters, here is an example: DI by Setter: public Class ObjectB {     // Internal reference to the ObjectC used by this ObjectB.     private ObjectC obj;     // Set the objectC that this ObjectB is to use. ...

In this article I want to show an implementation I made about the sorts algorithms, the most known widely are: Burble, SelectionSort, InsertionSort, MergeSort and QuickSort. The fastest are the QuickSort and MergeSort and unlike the others they use recursives calls and split the arrays to gain betters performance while sorting. Below I add a brief definition about each one: Bubble: This is a simple sorting algorithm, it start at the beginning of the data set and compares the first two elements and if the second is lower than the first it swaps them. The process continues comparing each adjacent element until the dataset’s end. The worst case performance of this algorithm is O(x^2). Selection: This is a simple sorting algorithm focus on an in-place comparison sort, looking the lowest element and moving to its corresponding place at the array. Its worst performance is O(x^2) making it inefficient with large arrays. Insertion: This is a simple sorting algorithm  that is rela...

The Design Pattern called Factory is focused on give instance to clients but hiding the way on how the instance is done. But why would we do that? Well there are several reasons why use it, image an escenario where you need to pass relevant and so sensitive data on the parameters to make your class work properly but you don't want to expose that information to the others module that will use your library , other scenario could be where you have several products implementing a particular interface and you don't have the way to figure out which product the client will and you must handle that and in our final escenario imagine you have important logic that need to be implemented by you before anyone could use a specific instance. There are a lot of examples of use where this pattern will solve several of your issues. The basis of this pattern is in the diagram below: In the next git example I use the Factory Pattern with a Singleton implementation. The Singleton is ...