Alguna vez has visto la lluvia ? caer en un día soleado ?

 

BIG DATA

 Hoy en día, en cambio, la recogida de datos masivos ha permitido

obtener información sobre la muestra completa (o casi)

de datos relacionada con el fenómeno que hay que evaluar, es

decir, toda la población. Por ejemplo, si una institución desea

analizar los tweets que tratan sobre un tema de interés público,

es perfectamente factible que pueda recoger todos aquellos

que hablen del tema y analizarlos. En este caso, el análisis no

pretende confirmar o invalidar una hipótesis, sino establecer

correlaciones entre distintas variables de la muestra. Por

ejemplo, supongamos que existe una fuerte correlación entre

el lugar de residencia de los vecinos de una ciudad y su opinión

ante una determinada problemática de esta. En este caso, podemos

explotar la relación que existe entre ambas variables

aunque no sepamos la causa que induce de la una a la otra.

Los datos masivos imponen un nuevo paradigma donde la

correlación «sustituye» a la causalidad. Determinar la causalidad

de un fenómeno pierde importancia, y en contraposición,

«descubrir» las correlaciones entre las variables se convierte

en uno de los objetivos principales del análisis.

Este cambio de paradigma provoca que los sistemas de big

data se centren en encontrar «qué» aspectos están relacionados

entre sí, y no en «por qué» están relacionados. Estos

sistemas pretenden responder cuestiones del tipo: ¿qué pasó?,

¿qué está pasando? y ¿qué pasaría si?, pero desde un punto de

vista basado en las correlaciones, donde no se busca la explicación

del fenómeno, sino solo el descubrimiento del fenómeno

en sí. En consecuencia, la causalidad pierde terreno a favor de

asociación entre hechos.

Habéis entendido algo... YO NO

Una aproximación a DDD - Parte I

 Diseño guiado por el dominio (DDD)

El diseño guiado por el dominio (DDD) es un enfoque para el desarrollo de software que propone un modelado rico, expresivo y evolutivo basado en la realidad del negocio. El dominio representa lo que hace una organización y la forma en que lo hace.

Con esta aproximación los expertos del dominio y los desarrolladores se sitúan en el mismo nivel empleando un lenguaje ubicuo. No hace falta ninguna traducción de términos entre ellos porque todos hablan un lenguaje común, que se plasma hasta en el código de programación. No es necesario que el lenguaje siga los estándares de la industria que representa: utiliza los términos y acciones que en el negocio se dan.

El lenguaje ubicuo que se usa crece y cambia con el paso del tiempo. Nadie es capaz de conocer el dominio de un negocio completo porque este forma parte de un proceso de descubrimiento continuo. Si la organización sigue una estrategia de desarrollo ágil, en cada iteración se refina el modelo de forma incremental y este plasma en todo momento el software en funcionamiento.

Para su tratamiento, las áreas independientes del dominio se transforman en contextos delimitados. Cada contexto delimitado es un límite explícito que tiene su propio lenguaje ubicuo. Un concepto tiene un significado dentro de un contexto delimitado, pero fuera de él puede tener un significado totalmente distinto. No se puede tratar de incluir todos los conceptos en un único contexto: se deben separar los conceptos en diferentes contextos y entender las diferencias que existen para un concepto llamado igual en uno y otro contexto.

¿Te has enterado de algo?, YO NO...

PRINCIPOS SOLID - ESQUEMATIZADO - SIN EJEMPLOS

S.O.L.I.D.

1.- SOLID es el acronimo qeu acuño Michael Feathers, basándose en los 5 principios de al programación orientada a objetos que Robert C. Martin había recopilado en el año 2000 en su paper "Design Principles and Dsign Patterns".

2.- Los objetivos de estos 5 principios a la hora de escribir código son:

a.- Crear un software eficaz: que cumpla con su cometido y que sea robusto y estable.

b.- Escribir un código limpio y flexible ante los cambios: que se pueda modificar fácilmente según necesidad, que sea reutilizable y mantenible.

c.- Permitir escalabilidad: que acepte ser ampliado con nuevas funcionalidades de manera ágil.

3.- La aplicación de los principios SOLID está muy relacionada con la comprensión y el uso de patrones de diseño, que permitirán minimizar el acoplamiento (grado de interdependencia que tienen dos unidades de software entre sí) y maximizar la cohesión (grado en que elementos diferentes de un sistema permanecen unidos para alcanzar un mejor resultado que si trabajaran por separado).

S.O.L.I.D.

S

Single Responsability Principle (SRP)

Principio de responsabilidad única

O

Open/Closed Principle (OCP)

Principio de abierto-cerrado

L

Liskov Substitution Principle (LSP)

Principio de sustitución de Liskov

I

Interface Segretation Principle (ISP)

Principios de segregación de interfaces

D

Dependency Inversion Principle (DIP)

Principio de inversión de dependencias

1.- Principio de Responsabilidad Única

a.- La S del acrónimo del que hablamos hoy se refiere a Single Responsability Principle (SRP). Según este principio "una clase debería tener una, y solo una, razón para cambiar".

Es esto precisamente, "razón para cambiar", lo que Robert C. Martin identifica como "responsabilidad".

b.- El principio de Responsabilidad Única es el más importante y fundamental de SOLID, muy sencillo de explicar, pero el más difícil de seguir en la práctica.

c.- El propio Bob resume cómo hacerlo: "Reúne las cosas que ambian por las mismas razones. Separa aquellas que cambian por razones diferentes".

2.- Principio de Abierto/Cerrado

a.- El segundo principio de SOLID lo formuló Bertrand Meyer en 1988 en su libro "Object Oriented Software Construction" y dice: "Deberías ser capaz de extender el comportamiento de una clase, sin modificarla" En otras palabras: las clases que usas deberían estar abiertas para poder extenderse y cerradas para modificarse.

b.- En su blog Robert C. Martin defendió este principio que a priori puede parecer una paradoja.

c.- Es importante tener en cuenta el Open/Closed Principle (OCP) a la hora de desarrollar clases, librerías, frameworks, microservicios.

3.- Principio de Sustitución de Liskov

a.- La L de SOLID alude al apellido de quien lo creó, Barbara Liskov, y dice que "las clases derivadas deben poder sustituirse por sus clases base".

b.- Esto significa que los objetos deben poder ser reemplazados por instancias o lo que es lo mismo: si en un programa utilizamos cierta clase, deberíamos poder usar cualquiera de sus subclases sin interferir en la funcionalidad del programa.

c.- Según Robert. C. Martin incumplir el Liskov Principle Subsitution Principle (LSP) implica violar también el principio de Abierto/Cerrado.

4.- Principio de Segregación de la Interfaz

a.- En el cuarto principio de SOLID, el tío Bob sugiere: "Haz interfaces que sean específicas para un tipo de cliente", es decir, para una finalidad concreta.

b.- En este sentido, según el Interface Segregation Principle (ISP), es preferible contar con muchas interfaces que definan pocos métodos que tener una interface forzada a implementar muchos métodos a los que no dará uso.

5.- Principio de Inversión de Dependencias

a.- Legamos al último principio: "Depende de abstracciones, no de clases concretas".

b.- Así, Robert C. Martin recomienda:

1.- Los módulos de alto nivel no deberían depender de módulos de bajo nivel. Ambos deberían depender de abstracciones.

2.- Las abstracciones no deberían depender de los detalles. Los detalles deberían depender de las abstracciones.

3.- El objetivo del Dependency Inversion Principle (DIP) consiste en reducir las dependencias entre los módulos del código, es decir, alcanzar un bajo acoplamiento de las clases.

GIT - Inglés y Cloud y Microservicios (básico para hoy en día)

Un poco de Git, es algo aburrido pero muy necesario como el inglés

 

Git commit frente a SVN commit

Aunque comparten el mismo nombre, git commit no tiene nada que ver con svn commit. Este término compartido puede ser una fuente de confusión para los principiantes de Git que tienen experiencia en SVN, y es importante recalcar la diferencia.

Comparar git commit con svn commit equivale a comparar un modelo de aplicaciones centralizadas (SVN) con un modelo de aplicaciones distribuidas (Git). En SVN, una confirmación envía los cambios del cliente SVN local a un repositorio SVN compartido, centralizado y remoto. En Git, los repositorios están distribuidos, las instantáneas se confirman en el repositorio local y no se require ninguna interacción en absoluto con otros respositorios de Git. Las confirmaciones de Git se pueden enviar más tarde a repositorios remotos arbitrarios.