jhontona.com

Etiqueta: Curso

  • Introducción a la minería de datos

    Introducción a la minería de datos

    El aprendizaje automático o supervisado hace parte de la minería de datos. Estos se concentran justamente en los modelos generados a partir de datos de naturaleza empírica, es decir, datos preexistentes resultado de un trabajo previo que no necesariamente estaban destinados a análisis de negocio, por ejemplo el histórico de ventas de un producto, su razón principal de ser es mantener un control sobre stock y ventas, pero a partir de estos registros podemos extraer mucha información relacionada con el producto. Actualmente este es el método mas utilizado, a partir de bases de datos existentes se hace el análisis de datos, de ahí el nombre de minería de datos, encontrar los valiosos patrones existentes en estas colecciones.

    Tenemos muchas metodologías que nos sirve de marco (KDD, SEMMA, ASUM-DM entre otras), la mas conocidas y utilizadas esta CRISP-DM.

    CRISP-DM

    Cross-Industry Standard Process for Data Mining, integra todas las tareas necesarias para los proyectos de minería de datos, veamos sus fases:

    Predicción

    En el aprendizaje supervisado tenemos dos tipos de problemas en función del tipo de salida, que llamaremos clase (variable objetivo):

    • Regresión: variable de salida es numérica (número real).
    • Clasificación. variable es categórica (número discreto o etiqueta nominal).

    Esta clase(predicción) se apoya en el conjunto de datos de entrada(dataset), en donde cada celda representa un dato de entrada; estos campos pueden ser de tipo numérico o categórico que llamaremos atributo, los cuales hacen parte de una instancia, es decir, una fila del dataset.

    dataset

    Las características principales para describir un data set son:

    • Número de instancias.
    • Número de atributos.
    • Nombre, tipo y breve descripción de cada atributo.
    • Tipo de datos de la clase, si tiene, y dominio de valores.
    • Nombre y breve descripción de la clase, si tiene.
    • Cantidad de valores ausentes.

    El dominio se refiere al conjunto de valores que puede tomar la clase.

    Principales roles

    Voy a listar algunos de los roles mas comunes:

    • Director técnico de proyecto(data scientist chief): Conocimientos de gestión y técnicos. Mucha experiencia en el campo.
    • Científico de datos(data scientist – ML engineer): Buena comunicación, selección de soluciones y estrategias. Fuertes bases matemáticas y de informática. MLOps.
    • Analista de datos(data analyst): Fuertes bases de estadística, conocer la inteligencia de negocio.
    • Ingeniero de datos(data engineer): Manejo de bases de datos, uso de herramientas y lenguajes para construir las soluciones.

    Para profundizar mas en estos roles recomiendo el artículo de The different data science roles in the industry

    Diferencia entre Bias y Varianza

    Tenemos tres tipos de errores:

    1. Error irreducible: Propio de los datos.

    2. Error de bias: Es la diferencia entre la predicción esperada de nuestro modelo y los valores verdaderos.

    3. Error de varianza: Se refiere a la cantidad que la estimación de la función objetivo cambiará si se utiliza diferentes datos de entrenamiento.

  • Spring Boot – Anotaciones

    Spring Boot – Anotaciones

    Segunda parte del curso Spring Boot

    En el anterior post hablamos de los conceptos básicos, y este es uno de los principales, pero merece un espacio propio.

    Tocamos temas sobre inyección de dependencias y beans, sin embargo no hablamos del ciclo de vida de estos componentes, por lo que vamos a empezar por ahí.

    Teníamos nuestro archivo XML para inicializar los beans y dijimos que podemos inicializar varios; en muchos casos estos beans dependen de otros, es decir que debemos inyectar las dependencias y comportamiento. Esto lo logramos usando la interfaz de BeanPostProcessor que nos permite crear objetos y asignar comportamientos antes y después de crear los beans con los metodospostProcessBeforeInitialization y postProcessAfterInitialization respectivamente. Lo que hace Spring es justamente en los anteriores métodos por medio de Reflexion instanciar los objetos necesario y asignar el comportamiento deseado. A partir de Spring 3.5 se implemento la autodetección de beans, es decir que ya no es necesario usar un XML para inyectar cada uno de nuestros beans. Esto se logra a través de las anotaciones.

    ¿Qué es una anotación?

    Una anotación es un metadato que se incrusta en el código, se caracterizan por iniciar con el carácter @, este no cambia el comportamiento del código pero si puede indicarle al compilador acciones especificas de lectura o ejecución, por ejemplo, Java por defecto tiene varias anotaciones, una de las mas conocidas es @Override que se utiliza para asegurar que un método heredado se sobrescribe. Así como ésta hay muchas mas y además se pueden crear anotaciones propias.

    Spring se vale de anotaciones para indicarte la la interfaz BeanPostProcessor como instanciar los beans. En el siguiente ejemplo busca la anotación @MyAnnotation:

    public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {
    Method[] methods = bean.getClass().getDeclareMethods();
    for (Method get Bean: methods) {
        if (method.getAnnotation(MyAnnotation.class) != null) {
            Class[] args = method.getParameterTypes();
            try {
                Object obj = context.getBean(args[0]);
                method.invoke(bean, obj);
            } catch (Exception e) {
                throw new RuntimeException(e);
            }
        }
    }
}

    Spring provee unas anotaciones por defecto, vamos a ver las principales.

    Anotaciones y componentes

    @Component

    Esta anotación le indica a Spring Boot que debe tratar la clase con el decorador como un bean, es decir que el propio motor se encargará de hacer la inyección.

    import org.springframework.stereotype.Component;

@Component
public class MyClass {

    @Repository, @Service y @Controller son especializaciones de @Component.

    @Repository

    Se utiliza para la capa de persistencia, en otras palabras, clases que interactúan con la base de datos. Tiene la particularidad de que tiene un control de errores mas especifico para interactuar con la sintaxis de base de datos, causando un mejor manejo de estos objetos.

    @Service

    Este se utiliza en la capa de servicio, es decir que se espera que sea lógica de negocio.

    @Controller

    Esta anotación nos enlaza con la capa de presentación, allí solemos colocar las urls que se exponen vía web.

    @Controller
@RequestMapping("students")
public class StudentController {

    @GetMapping("/{id}", produces = "application/json")
    public @ResponseBody Student getStudent(@PathVariable int id) {
        return studentService.getStudentById(id);
    }
}

    Esta anotación se suele usar mucho en los servicios web junto con la anotación @ResponseBody que permite mapear nuestra respuesta a un objeto JSON.

    Ya que este tipo de comportamiento es el mas común, desde la versión 4.0 de Spring se creo una nueva anotación que los incluye a ambos:

    @RestController

    @RestController
@RequestMapping("students")
public class StudentController {

    @GetMapping("/{id}", produces = "application/json")
    public Student getStudent(@PathVariable int id) {
        return studentService.getStudentById(id);
    }
}

    @Autowired

    Esta anotación nos sirve para indicarle que vamos a inyectar un bean dentro de otro, es decir como una propiedad o también lo podemos usar en los métodos set; esto quiere decir que podemos darle el control al framework para que cree la instancia de los componentes, esto es importante ya que solo podemos utilizar esta anotación para inicializar componentes definidos en el contexto de Spring, es decir, que tengan el decorador @Component o alguna de sus especializaciones.

    En el siguiente ejemplo se muestra la instanciación de un servicio como propiedad de otro bean(controlador):

    @Service
public class StudentService {
    @RestController
@RequestMapping("students")
public class StudentController {

    @Autowired
    private StudentService studentService;

    @GetMapping("/{id}", produces = "application/json")
    public Student getStudent(@PathVariable int id) {
        return studentService.getStudentById(id);
    }
}

    Con esta anotación nos surge un problema que vamos a ilustrar a continuación:

    @Service
public class StudentService implements PersonService {
    @Service
public class TeacherService implements PersonService {

    La idea es que queremos inicializar una instancia de la interfaz PersonService, en este caso hay dos posibles orígenes y @Autowired no sabría cual implementar, para solucionar esto podemos usar la anotación @Qualifier de la siguiente manera:

    @Service
@Qualifier("student")
public class StudentService implements PersonService {
    @Service
@Qualifier("teacher")
public class TeacherService implements PersonService {
    @RestController
@RequestMapping("registration")
public class RegistrationController {

    @Autowired
    @Qualifier("student")
    private PersonService personService;

    @GetMapping("/info/{id}", produces = "application/json")
    public Person getDataPerson(@PathVariable int id) {
        return personService.getBasicDataById(id);
    }
}

    De esta manera podemos indicarle específicamente que tipo implementar. En el anterior ejemplo obtenemos la instancia del servicio StudentService.

    @Value

    Esta anotación nos sirve para inyectar valores en los campos de un constructor o método. En el siguiente ejemplo se obtiene un valor del archivo .properties y se le asigna a una variable. Podemos ver el @Value asignado a diferentes tipos de datos e incluso establecemos un valor por defecto.

    @Service
@Qualifier("teacher")
public class TeacherService implements PersonService {

    @Value("${university.class.code:default}")
    private String code;

    @Value("${university.class.subjects}")
private String[] subjects;

    @Scope

    El Scope o ámbito indica el alcance de una instancia, en Spring tenemos por defecto la instancia de los beans como singleton (se crea una única instancia del beans, es decir que las siguientes instancias del mismo bean hacen referencia al único creado); como se mencionó por defecto funciona así, aunque si queremos especificarlo se hace de la siguiente manera:

    @Bean
@Scope("singleton")
public University university() {
    return new University();
}

    En el anterior post también mencionamos que se pueden establecer los beans por medio de xml, para ese caso también podemos definir el scope.

    <?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">

    <bean id="personService" class="com.jhontona.service.PersonServiceImpl" scope="singleton" />
    <!--También podemos usar singleton="true" -->
</beans>

    También podemos definir el alcance como prototype, el cual crea una instancia nueva en cada llamado.

    @Bean
@Scope("prototype")
public Teacher teacher() {
    return new Teacher();
}

    Los anteriores scopes se pueden usar en cualquier aplicación de Spring, pero además tenemos scopes específicos para el ámbito web(Web Aware).

    El scope de Request se utiliza para crear una instancia nueva de bean por cada petición http, es decir que su uso mas común es con un @RestController aunque también lo podemos definir para un @Bean.

    @Bean
@Scope(value = WebApplicationContext.SCOPE_REQUEST)
public ExampleBean exampleBean() {
    return new ExampleBean();
}
    @RestController
@RequestScope
public class ExampleController {

    @GetMapping("/test")
    public String sayHello() {
            return "Hello";
    }

}

    El scope de Session se utiliza para crear una instancia nueva de bean por cada sesión http

    @Bean
@Scope(value = WebApplicationContext.SCOPE_SESSION)
public ExampleBean exampleBean() {
    return new ExampleBean();
}
    @RestController
@SessionScope
public class ExampleController {

    @GetMapping("/test")
    public String sayHello() {
            return "Hello";
    }

}

    El scope de Global Session se utiliza para crear una instancia nueva de bean por cada sesión http, pero este va orientado a Portlets, es decir aplicaciones que trabajan con módulos reutilizables de este tipo; las características principales de este tipo de aplicación es que dependen de un contenedor especializado en controlar estos módulos, además de que cada pagina puede estar constituida por múltiples portlets y cada una de estos tiene un request y response independiente.

    @Bean
@Scope(value = WebApplicationContext.SCOPE_GLOBAL_SESSION)
public ExampleBean exampleBean() {
    return new ExampleBean();
}

    El scope de Application se utiliza para crear una instancia nueva de bean por cada ServletContext, que por lo general en una aplicación es único(aunque podemos crear mas), comportándose como un singleton.

    @Bean
@Scope(value = WebApplicationContext.SCOPE_APPLICATION)
public ExampleBean exampleBean() {
    return new ExampleBean();
}
    @RestController
@ApplicationScope
public class ExampleController {

    @GetMapping("/test")
    public String sayHello() {
            return "Hello";
    }

}

    El scope de WebSocket se utiliza para crear una instancia nueva de bean por cada websocket.

    @Bean
@Scope(scopeName = "websocket")
public ExampleBean exampleBean() {
    return new ExampleBean();
}

    Tenemos un montón de anotaciones, pero las que hemos visto son las de uso mas frecuente o nos ayudan a entender los comportamientos por defecto que toma una aplicación en Spring (si se quiere profundizar mas en estas anotaciones le recomiendo este recurso).

    Anotaciones Javax

    Con las anotaciones propias de Spring tenemos para adaptarnos a una gran variedad de situaciones, sin embargo podemos trabajar con anotaciones propias del lenguaje o provistas por paquetes externos, por ejemplo, Javax Annotation API tiene unas anotaciones interesantes que se integran con Spring.

    @PostConstruct and @PreDestroy nos sirve para llamar un método después de la instanciación del bean o antes de su destrucción, es decir que funciona como un callback.

    import javax.annotation.*;

public class ExampleController {

    public String sayHello() {
            return "Hello";
    }

    @PostConstruct
    public void init(){
        System.out.println("El Bean se acaba de inicializar.");
    }
   
    @PreDestroy
    public void destroy(){
        System.out.println("El Bean se va a destruir.");
    }

}

    Contamos con otras etiquetas como @Resource e @Inject que se comporta de manera muy similar al @Autowired por lo que teniendo alternativas en Spring es mas practico. Simplemente debemos saber que podemos crear o insertar anotaciones desde otros paquetes.

    Hasta aquí llega este post, espero tus preguntas, comentarios y que compartas este contenido.

  • Spring Boot – CORE

    Spring Boot – CORE

    ¿Qué es Spring Boot?

    Es un framework de código abierto para desarrollo de aplicaciones para JVM, es decir que trabajamos principalmente con Java; sin embargo, también provee soporte para lenguajes como Groovy y Kotlin.

    Este framework nos permite implementar diversas arquitecturas y estilos de aplicación dependiendo de la necesidad del proyecto. Trabaja con versiones de JDK superiores al 8. A demás nos provee diferentes entornos de trabajo:

    • Despliegue en un servidor propio
    • Despliegue en servidor embebido
    • Despliegue en la nube

    Dentro de estos entornos nos provee una estructura modular, es decir que iremos conectando las diferentes piezas que requiera nuestra aplicación.

    Trabajando con Spring Boot

    Spring Boot nació como respuesta a las exigencias de los estándares de la comunidad de desarrollo, por este motivo intrínsecamente implementa estándares y buenas practicas, al  igual que nos propone la siguiente filosofía de diseño:

    1. Establecer altos estándares de calidad para el código.
    2. Preocúpese por el diseño de la API.
    3. Mantenga compatibilidad con versiones anteriores.

    Estas reglas las ofrece de manera automática, es decir que se implementan casi al instante, esto se logra a través de, como mencionamos antes, conectar diferentes módulos(inyección de dependencias). A demás implementa estas reglas en su propio desarrollo a partir de ser un framework que ofrece opciones en todos los niveles de aplicación y se acomoda a las diversas necesidades.

    Los módulos de Spring Boot están orientados de tal manera que podamos identificar tres capas principales:

    • Capa de presentación.
    • Capa de Negocio.
    • Capa de persistencia.

    Esta forma de trabajo modular es la que lo convierte en uno de los mas populares frameworks para Java, a demás de otros subsistemas de los cuales no hemos mencionado, como : logging, web services, seguridad, automatización de pruebas, entre otros.

    Spring Boot permite a los desarrolladores enfocarse mas en la lógica de negocio y menos en problemas de plomería.

    Conceptos claves

    Inyección de dependencias

    La inyección de dependencias es un patrón de diseño en donde se le suministran objetos a una clase en lugar de ser la propia clase quien los crea.

    Bean

    El Core de Spring Boot es un contenedor que se encarga de orquestar beans(objetos gestionados). Estos beans son objetos de tipo POJO, es decir que son clases simples con sus atributos privados a los cuales se pueden acceder por métodos get y set.

    Cumpliendo con el patrón de inyección de dependencias, proveemos estos beans a los módulos de Spring Boot indicándole su forma de instanciación y correlaciones entre ellos; el Core se encargara de implementarlo.

    Inversión del control

    Este principio de software es uno de los pilares de Spring Boot, consiste en darte el control de los objetos al propio framework, es decir que el framework será el encargado de instanciar nuestras clases y reproducir el comportamiento que deseamos a partir de la configuración que le seteamos.

    Las principales ventajas de este principio es que logra modularizar nuestra aplicación permitiendo tener nuestra lógica compacta y aislada, repercutiendo en la mantenibilidad y facilidad de implementación de pruebas.

    Para implementar este principio(IoC, Inversion of Control) se utiliza en Spring Boot la inyección de dependencias, anteriormente ya lo habíamos mencionado, para ver la diferencia vamos a plantear un ejemplo:

    Código tradicional

    public class Person {
    private Document document;
    
    public Person() {
        document = new Document();
    }
}

    Inyección de dependencias

    public class Person {
    private Document document;
    
    public Person(Document document) {
        this.document = document;
    }
}
    ApplicationContext

    El ApplicationContext es una interfaz que nos permite implementar IoC, es decir, la instanciación  y el control del ciclo de vida e interacción entre objetos. Se encarga de procesar nuestros beans.

    Spring provee diferentes implementaciones de esta interfaz:

    • ClassPathXmlApplicationContext
    • FileSystemXmlApplicationContext
    • WebApplicationContext

    El proceso de implementacion de, por ejemplo, ClassPathXmlApplicationContext es:

    1. Crear archivo de configuración XML(/src/main/resources/beans.xml) para los beans. 
      <?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">

    <bean id="personService" class="com.jhontona.service.PersonServiceImpl" />
</beans>
    2. Implementar el ApplicationContext, en este caso en las pruebas unitarias(/src/test/java/com/person/service/PersonServiceTest.java) 
      package com.person.service;
import static org.junit.jupiter.api.Assertions.assertNotNull;

import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;
import org.springframework.context.support.ClassPathXmlApplicationContet;

public class PersonServiceTest {
    private ClassPathXmlApplicationContext context;
    private PersonService service;

    @BeforeEach
    void setUp() {
        context = new ClassPathXmlApplicationContext("beans.xml");
        service = context.getBean("personService", PersonService.class);
    }

    @Test
    void testGetOnePerson() {
        assertNotNull(service);
    }
}

    Este archivo de beans.xml podemos personalizarlo dependiendo de nuestras necesidades, por ejemplo, podemos colocarle uno o varios alias a nuestro bean:

    <bean id="personService" name="alias1,alias2" class="com.jhontona.service.PersonServiceImpl" />

    Al bean le podemos indicar acceder a un constructor especifico o un método setter, ejemplo:

    Constructor

    public PersonService(String name, Integer age, Boolean document) {
    <bean id="personService" class="com.jhontona.service.PersonServiceImpl">
    <constructor-arg name="document" value="true"/>
    <constructor-arg index="0" value="Juanito"/>
    <constructor-arg value="19"/>
</bean>

    Estos atributos los podemos pasar por nombre, índice, tipo u orden de los argumentos.

    A demás, podemos tener tantos beans como queramos. y hacer referencia entre ellos con el atributo ref.

    Hasta aquí esta breve introducción a Spring Boot, vimos algunos puntos claves a cerca del ecosistema de Spring.

  • Arquitectura empresarial – Implementación

    Arquitectura empresarial – Implementación

    TOGAF Standard, Versión 9.2 año 2018

    Anteriormente habíamos creado la especificación. Ahora, es momento de hacer la transición de esa arquitectura. Para eso pasaremos por dos fases mas del proceso ADM. La fase de oportunidades y soluciones, y la fase de planeación de la migración. Recordemos que teníamos los documentos generados de las fases anteriores. Donde se encuentra el estado actual y futuro de esa arquitectura. Lo que se denomino como brecha. Así que ahora comenzamos nuestra planeación a partir de esas salidas.

    En nuestra fase de oportunidades y soluciones comenzamos a analizar conceptualmente las entradas que hemos recibido. Es decir, esta fase se convierte en una especie de repositorio en donde evaluamos los aspectos funcionales y no funcionales a través del tiempo. ¿Por qué siempre se trabaja sobre el tiempo? Muy sencillo, por que puede que hallan funcionalidades que no sean relevantes durante la implementación que se está corriendo pero si para posteriores desarrollos. Esto es muy importante identificarlo. Ya que se deben orientar los esfuerzos al desarrollo e implementación de estructuras que representen valor para la empresa. Para conseguir esto podemos utilizar diferentes herramientas para validar el impacto, por ejemplo, una gráfica de tiempo y ubicar las funciones dentro de ese espectro o un gráfico de valor estratégico frente a la complejidad. Lo importante no es con que, si no su resultado.

    Bien, ahora como podemos identificar esas características como funcionales y no funcionales. Esto también es muy fácil de identificar. Los aspectos funcionales son aquellos que explican como desarrollar alguna actividad o proceso. Y los no funcionales se orientan a la calidad. Es decir, me permiten medir y validar los aspectos funcionales. Por ejemplo, funcional seria la gestión de clientes y no funcional las métricas que se utilizan dentro de ese proceso.

    Una vez se detectan las soluciones a implementar hay que avanzar a la siguiente fase de ADM. Para hacer este paso podemos utilizar tres herramientas.

    1. Matriz de interoperabilidad: Para entender la interoperabilidad dentro de la arquitectura. Es decir, conocer cómo se comunican los diferentes elementos de la arquitectura.
    2. Evaluación de la preparación al cambio: Consiste en medir que tan preparada esta la organización para aceptar el cambio que se propone. TOGAF propone El programa de transformación y capacitación del negocio. Aunque estas no son camisa de fuerza. Recordemos que este marco es muy flexible frente a estos aspectos. Y hay que si o si hacer esta tarea. Ya que la mayoría de veces la arquitectura falla por que la organización no esta dispuesta a aceptar el cambio. A continuación, listare algunos aspectos con los que se debe trabajar para poder evaluar la preparación al cambio. Esto para evitar esa resistencia al cambio. Y poder efectuarla de la manera mas transparente posible.
      • Visión
      • Deseo de cambio
      • Las necesidades
      • Biz case: Caso de negocio y urgencia
      • Financiación
      • Inversión
      • Gobernabilidad
      • Responsabilidad
      • Enfoque definido
      • Capacidad de TI
      • Capacidad departamental
      • Implementación de los cambios
      • Operación final de los cambios
    3. Matriz de impacto vs probabilidad: Sirve para gestionar los riesgos y ver su impacto en la organización.

    Ahora si podemos iniciar con la fase de planificación de la migración de ADM. En esta fase debemos trabajar muy de cerca con la gestión de proyectos. Teniendo en cuenta sus pilares.

    Si lo vemos desde este punto de vista, podemos ver que el arquitecto empresarial no es la mejor opción. A menos de que cuente con la experiencia y herramientas de gestión de proyectos. Aunque esto no suele ser una buena opción. Ya que cada una requiere cierta disciplina.

    Como hemos mencionado anteriormente. Cada fase de ADM genera un entregable (documento). Esta fase no es la excepción. Aquí nuestro objetivo es generar un diagrama de Gantt detallado o un plan de migración o un plan de ruta. Junto con un contrato de arquitectura. Que básicamente es el plano de la arquitectura que se piensa implementar. Aquí se definen claramente los objetivos y recursos necesarios. Para esta fase orientamos nuestro esfuerzo a analizar el modelo estratégico, arquitectónico y de solución. Podemos tener una perspectiva de análisis y revisión de abajo hacia arriba o viceversa.

    Después de esta fase lo que generamos como tal es la arquitectura. Es decir que ahora estamos en la fase de gobierno de la implementación del proceso ADM. Ya tenemos nuestro producto listo para implementar, las estrategias definidas y el plan de implementación. Así que nuestro foco es revisar ese entregable y ver como el equipo de desarrollo ejecuta la arquitectura y la implementación. Para esto dentro del contrato de arquitectura van los lineamientos, además de todos los entregables que se tienen hasta ahora. Para ir evaluando y midiendo el avance. Algo importante es que dividimos la carga arquitectónica en varios niveles, por lo que es importante evaluar cada uno de estos y no solo a nivel global.

    Ahora que se está implementando la arquitectura, pueden surgir cambios. Estos cambios van enfocados a cambios de la propia arquitectura. Por ejemplo, durante la implementación se detectó que un proceso de la organización no se adapta completamente a un bloque que se creó. Hay dos alternativas, modificar el bloque o reestructurar el proceso arquitectónico. Cualquiera de las dos opciones me va a generar un proceso de implementación incremental o un nuevo proceso de ADM.

  • Arquitectura empresarial – Desarrollo

    Arquitectura empresarial – Desarrollo

    TOGAF Standard, Versión 9.2 año 2018

    Dentro del enfoque de ADM, como primera etapa teníamos la fase preliminar. Es justo allí donde empieza el desarrollo de la arquitectura. Vamos a definir como podemos dividir la complejidad de la organización en partes mas pequeñas, que realmente podamos reusar. Esto porque es muy difícil trabajar con la organización desde el inicio en su estado total. No podemos trabajarla correctamente si no hacemos la labor de ingeniería inversa.

    Para entender la complejidad de una organización se puede dividir en segmentos. Según la escala podríamos hablar de países, sucursales, departamentos, etc. Hasta llegar a un punto en donde nos sentimos cómodos y ponemos iniciar con el análisis.

    Estos segmentos se analizan teniendo en cuenta el tiempo. Y como a través de el se descompone la capa estratégica en bloques de construcción. Que pueden tener tantas versiones como sea necesario, hasta el punto en que se pueda generar un componente ejecutable. Lo trato de decir es que en realidad buscamos es ampliar el nivel de detalle. Pasamos de conceptos abstractos (estrategias) a descomponerlo en los espacios de capacidad. Este proceso de descomposición lo logramos gracias a las iteraciones que vamos ejecutando del proceso de ADM sobre cada una de las capas. Esto permite una disciplina y consistencia durante la creación de la arquitectura.

    Se van creando los bloques de manera orgánica. Ya que al llegar a la visión arquitectónica vamos a identificar las unidades necesarias para este bloque. Lo cual me genera la necesidad de descomponer en bloques mas pequeños. Es decir que vamos a tener varios procesos ADM anidados.

    Cuando identificamos los aspectos y características necesarias en la fase de visión arquitectónica, se genera un documento de visión de la arquitectura. Que explica que es lo que se trata de hacer, en qué nivel (capa) se encuentra y algunos otros factores de los que depende.

    También identificamos las piezas de Tecnología de Aplicación de Datos de Negocios (BDAT), las cuales necesitan ser ensambladas para generar esa estrategia con la que estamos trabajando. Otro elemento importante que se tiene en cuenta, son los cambios que se deben hacer o la preparación que se debe tener para lograr la estrategia. Y, por Último, pero no menos importante. Detalla quienes son los interesados y de qué forma intervienen.

    Otro dato importante que muestra este documento es el tiempo, costo y esfuerzo. Pilares fundamentales para la gestión de proyectos. Este documento se firma y es, podríamos llamarlo, el primer contrato dentro de la visión arquitectónica.

    Anteriormente mencionamos que son varios procesos ADM anidados, pero son los primeros, en donde tomamos las estrategias, los que se convierten en el motivador empresarial. Es decir, son mis macroproyectos y rutas a seguir. Los demás me sirven para modelar como tal la arquitectura y generar mis bloques de procesos y funciones. Los primeros documentos que surgen de la visión arquitectónica, por lo general son los que utiliza la gerencia de la organización. Ya que estos contienen el lenguaje y recursos que estos necesitan.

    La descomposición por medio del marco ADM de TOGAF me debería dar como resultado la definición de la organización en una jerarquía descendente. Es decir, primeramente, la visión, luego las metas, objetivos, tácticas, etc.

    La motivación empresarial (visión) es importante definirla y alinearla con las actividades propias del negocio y la base tecnológica de la organización. Para luego, lo que se desprende de ella se encamine a desarrollarla. Lo que quiere decir es que los objetivos que se definan para cada uno de estos procesos deben ser inteligentes (específicos, medibles, accionables y realistas en el tiempo).Los interesados. Que son, cualquier persona que se vea afectada por el por el resultado del proceso. Son quienes definen la visión y viabilidad de la arquitectura. En el anterior post ya habíamos hablado un poco sobre los puntos de vista y como se utiliza. Así que no profundizare mucho en este tema. Pero recordemos que nos generan una lista de preocupaciones y necesidades. Con las cuales se evalúan los modelos arquitectónicos que se van generando. Y estos modelos deben contestar a esa lista de uno a uno. Es decir, no se permiten mas ni menos características de las que los interesados requieren.

    Entonces, tenemos nuestro documento de puntos de vista, los interesados y algunos bloques de construcción definidos. Lo que se hace es tomar la descripción de estos puntos de vista y los bloques necesarios para ensamblar y desarrollar la visión que se tiene. Por ejemplo, el interesado, llamémoslo gerente, requiere de un reporte donde se muestre cierta información. Tenemos nuestro requisito definido y ahora tomamos las vistas disponibles, es decir gráficos, tablas, etc. En donde se pueda mostrar los componentes que el gerente requiere, que en este caso seria los datos que solicitó. Podríamos definir hasta ahora los siguientes pasos:

    1. Documento de puntos de vista
    2. Identificación de modelos de referencia
    3. Inicio de proceso arquitectónico (Evaluación de estado actual)
    4. Definición del estado futuro
    5. Cambios que debo implementar para pasar de la condición actual a la deseada (brecha)

    Ahora, toquemos un concepto que es muy importante y es la planificación de escenarios de negocio. Que engloba como tomamos los requisitos del negocio, como se modela y como planificamos con ellos en una serie de escenarios.

    La planificación del escenario de negocio, inicia en la fase de visión arquitectónica dentro del proceso de ADM y nuestro objetivo es pasar dentro del escenario de un espacio problemático a uno con una solución que encaje en nuestro modelo de motivación. Este paso requiere un proceso, y es muy importante documentar desde el problema hasta su solución para alimentar nuestra librería de conocimiento.

    1. Se debe definir el problema y comprenderlo.
    2. Se debe identificar el medio en el que se desarrolla. Es decir, el momento, interesados, lugar y condiciones en que está ocurriendo. Ya que esto afecta a la estrategia y tácticas a usar.
    3. Usar modelos para documentar la brecha. Podemos utilizar casos de uso, modelos de notación, etc.

    Una vez tenemos identificadas las piezas necesarias que apoyan nuestro negocio. Comenzamos a construir con los bloques definidos esa solución. Y lo hacemos a través de la creación de un modelo de anclaje de negocio. Que como resultado genera nuestra visión del modelo de desarrollo de la arquitectura de negocio. Que está comprendido por:

    • Modelo de mercado: Se enfoca en los clientes y la relación con ellos.
    • Modelo de productos y servicios: Mira cuales son mis propuestas de valor en el mercado (Productos y servicios).
    • Modelo operativo: Como trabaja la organización.

    La idea es tomar la problemática y solucionarla por medio de la eficiencia y eficacia. Es decir, generando esos objetivos inteligentes de los que habíamos hablado. De estos objetivos surgen los artefactos clave dentro de la arquitectura. Y estos artefactos son el modelo de anclaje del negocio. Que es lo que permite hacer frente a las diversas dificultades y cambios que enfrente la organización.

    Ahora podemos comenzar a generar nuestro producto y ver como se vincula a nuestra área tecnológica. Trabajaremos sobre el dominio de aplicación y el dominio de datos. Si ya se tiene el dominio de datos, se puede iniciar a partir del documento de especificación de arquitectura de datos. Aunque realmente este documento se puede generar antes o después de la arquitectura de la aplicación.

    En la arquitectura de la aplicación se necesita identificar que se debe desarrollar. Por ejemplo, una nueva plataforma de software o en el caso de los datos una nueva base de datos o simplemente tablas o campos que se deben agregar. Pero nunca perder el foco, es decir tener siempre presente los requisitos y vistas que dieron los interesados. También se debe conocer cual es la pieza que desarrollo, ¿es una función o un proceso? Con esto logramos crear una relación entre la capacidad y el proceso o función.

    Ahora que tenemos la capacidad de poner en marcha esa aplicación debemos relacionarla con el negocio. Es decir, como el nuevo producto tecnológico trabaja con los datos que se obtienen de los procesos de negocio y se alinean para generar los resultados esperados. Esto es lo que llamamos arquitectura de datos. Una aplicación puede estar conformada por varios de los bloques de procesos de la arquitectura. Y hablando a nivel de informática, se puede orientar a una arquitectura por servicios. Donde cada servicio podría apuntar a un bloque de la arquitectura empresarial.

    Hasta ahora solo habíamos definido la especificación del producto. Que característica iba a tener, como se iba a comportar frente al negocio y como se vincularía a nuestra plataforma tecnológica. Pero ahora llegan las preguntas de ¿Cómo se va a usar?, ¿Cómo se va a desarrollar?, es mas , muchas veces no es necesario desarrollar el producto, ya existe y es ver como lo puedo implementar, ya que, ya tengo claro cuál es el producto que necesito. Por ejemplo aquí podríamos integrar La Biblioteca de Infraestructura de Tecnologías de Información (ITIL). Para que nos ayudase a gestionar e identificar los recursos tecnológicos.

    Hemos llegado a una parte importante dentro del proceso de ADM. Por ahora vamos a dejar hasta aquí. Pero antes recordar que en cada etapa del proceso ADM generamos uno o varios entregables. Que como mencionamos TOGAF suele trabajar con diferentes marcos, así que de estos depende los documentos o salidas que generamos.

  • Arquitectura empresarial – Marco

    Arquitectura empresarial – Marco

    TOGAF Standard, Versión 9.2 año 2018

    La arquitectura empresarial es una disciplina cuyo objetivo es ayudar a las organizaciones a hacer frente a diferentes tipos de retos, especialmente enfocado en la toma de decisiones. Basado en un marco definido. También pretende integrar a estas soluciones una base tecnológica que soporte y aporte valor.

    Podemos ver la arquitectura empresarial como la manera de entender e integrar cada una de las piezas que conforman una empresa (departamentos, funciones, procesos, recursos, etc.); con el único objetivo de tener éxito, es decir que la organización sea productiva y eficiente. También permite dentro de este análisis reconocer limitaciones y posibles estados o rumbos que puede tomar la organización, es decir un reconocimiento de precedentes, estado actual y proyección.

    Para resumir. La arquitectura empresarial permite crear una organización cohesiva, altamente estable pero lo suficiente mente flexible para adaptarse a los cambios.

    Anteriormente se menciono la necesidad de un marco. Lo que este permite es reducir las amenazas o riesgos, prolongar las ventajas y crear o construir nuevas oportunidades. Funciona como un filtro en donde pasamos cada uno de los procesos, objetivos y estrategias de la organización con el fin de identificar y evaluar para posteriormente poder tomar decisiones. La idea es poder generar ideas inteligentes e innovadoras donde nuestro negocio se adapte y así pueda crear una diferenciación frente a la competencia.

    TOGAF

    Esquema de Arquitectura del Open Group. Nos va a ayudar a entender como construir la capa de utilidad de una organización. Es decir, nos plantea unos pasos y define unos bloques que se pueden identificar dentro de la organización para así­ convertirlos en procesos de negocio repetibles.

    TOGAF tiene la caracterí­stica de que funciona muy bien con otros marcos y metodologí­as, haciendo que estas trabajen juntas y crea cierta interrelación. Por este motivo a tomado mucha relevancia dentro de esta disciplina. Y se ha creado una comunidad inmensa que apoya y desarrolla este marco.

    El trabajo con este marco se puede asemejar a un set de lego, en donde encontramos diferentes piezas, de diversos tamaños, formas y colores. Aun así­, esto se puede clasificar por varios criterios y en conjunto forman una increí­ble estructura. Justamente lo que pretende TOGAF es poner un orden en estas piezas, que en realidad son las que conforman la organización. De manera que al identificarlas podamos trabajar más fluida y organizadamente.

    Cuando creamos una arquitectura basada en TOGAF, tenemos un cubo (repositorio) donde encontramos las piezas que ya hemos construido y a partir de estas podemos crear nuevos bloques o estructuras. A estos nuevos bloques(resultados) los podemos identificar como todos aquellos insumos (documentos, instructivos, manuales, artefactos, etc.) que se usan para apoyar procesos o funciones. Teniendo clara esa perspectiva podemos ver la alta escalabilidad que provee este marco. Ya que permite reusar piezas y construir a partir de modelos conocidos.

    Dentro del marco de TOGAF, al cubo de piezas se le denomina como el Continuo Empresarial. Es donde tenemos la base de la arquitectura. Esta base está compuesta por dos partes. El Continuo de la Solución y el Continuo Arquitectónico.

    En el Continuo arquitectónico se definen los aspectos lógicos y en el Continuo de la solución se describe la solución propiamente dicha. Para entenderlo un poco mejor se plantea el siguiente ejemplo: En el continuo arquitectónico se plantea como objetivo la gestión de relaciones con los clientes; mientras que en la solución se definen las herramientas y como se integran con la lógica que se definió.

    Podemos tener tantos bloques como sean necesarios, tanto el en el continuo de la arquitectura como en el de la solución. Estos bloques pertenecen a un estado de maduración dentro de la organización, también se puede ver como el estado de desarrollo del mismo.

    A continuación lo veremos en detalle para comprenderlo mejor.

    En el continuo arquitectónico tenemos bloques de

      • Fundación arquitectónica (Pequeños bloques preconstruidos): Material genérico.
      • Arquitectura común (Sistemas comunes): Modelamos el material genérico para convertirlo en una pieza más especí­fica.
      • Arquitectura industrial: Tomar por completo o una parte de una arquitectura o modelo externo para adaptarlo a la organización.
      • Arquitectura organizacional: Son los bloques que ya son parte de la organización.

    Podemos ver la anterior lista como un proceso de desarrollo, en donde tenemos una materia prima. Por ejemplo, aplicándolo a una empresa, un conjunto de datos de los clientes. Puedo modelar estos datos de tal manera que sean de utilidad para la organización, es decir, pasarlo por cada uno de estos í­tems(fases) para hacerlos parte de la organización. En otras palabras, a partir de unos datos en bruto generar un sistema de CRM, por ejemplo.

    En el caso del Continuo de la solución tenemos los mismos bloques, obviamente aplicados a la solución de lo que se planteó en la lógica de la arquitectura.

    Al realizar este proceso de categorización, logramos una mayor comprensión de donde encontrar estas piezas de manera mas efectiva. TOGAF provee un Modelo de Referencia Técnica (TRM) y un Modelo de Referencia de Infraestructura de Información Integrada (III-RM). En estos se describe el desarrollo del levantamiento de esta información, la clasificación y análisis y como integrarlo a una infraestructura tecnológica.

    Comunicación: Lenguaje común

    La arquitectura empresarial en su definición y forma de implementación depende totalmente del o los arquitectos que la estén integrando. Hay que tener en cuenta que todas las organizaciones son diferentes y por ende las soluciones también deben serlo. TOGAF pretende establecer un lenguaje común para indicar como un bloque se relaciona con otro. De esta manera al heredar el proyecto esta el medio para poder entender e interpretar como funcionan estas piezas en su conjunto.

    Estos modelos se encuentran dentro del marco del contenido y se denominan metamodelos. Lo que realmente describe es cada uno de los procesos y sobre todo los datos de entrada y salida de cada uno de estos. Con el objetivo de poder coger estas piezas (procesos) y poderlos conectar. Sabiendo que recibo y espero de cada uno de estos. Por ejemplo, podemos identificar qué tipo de dato genera la salida de un proceso y como esta salida se relaciona con la entrada de mi siguiente proceso. Y podemos ir más allá e identificar y crear nuevos procesos que van heredando los recursos, para así­ crear una cadena de producción y activos reutilizables.

    Gestión del Conocimiento

    TOGAF-CONOCIMIENTO.jpg

    Es muy importante para las empresas, sobre todas las grandes o con una larga trayectoria, gestionar su conocimiento. Es decir, poder tener un repositorio donde consultar esos aprendizajes y cambios que ha vivido a través del tiempo. En nuestro tema de estudio esto se llama el repositorio de conocimiento arquitectónico. Permite organizar y gestionar el conocimiento de la arquitectura de manera efectiva.

    En el anterior grafico se muestra la representación de una arquitectura empresarial. Bajo el marco establecido por TOGAF. Lo que se pretende es capturar a la organización en un tiempo específico, puede ser presente o una visión a futuro. En donde se muestra la capacidad y segmentación estratégica de la organización.

    Dentro de esta arquitectura vemos un espacio asignado a una biblioteca de referencia. Es el lugar donde reposa la definición de los bloques de construcción arquitectónica y el continuo arquitectónico. También se tienen enlaces y referencias a otros elementos de la arquitectura para su definición.

    Este conocimiento es realmente importante y esencial en la toma de decisiones, he influye en el log de gobierno de la empresa.

    Aquí se evidencia la capacidad arquitectónica, roles, responsables y procedimientos. Así que a pesar de ser solo contenido teórico y descriptivo es una gran fuente de información y ayuda en las decisiones, generación de documentos y creación de otros bloques de procesos.

    Método de Desarrollo de Arquitectura (ADM)

    ADM nos muestra el proceso a seguir para la implementación, desarrollo y mejora de la arquitectura. A continuación lo veremos de manera muy general, ya que mas adelante veremos el ciclo en detalle.

    En ADM iniciamos con una fase Preliminar. En donde se establece el repositorio arquitectónico, donde ya se encuentran los artefactos, entregables y recursos definidos. También entran aquellos nuevos requisitos que se quieren modelar dentro de la arquitectura. Por ejemplo, un nuevo producto.

    Estos entregables y productos que se generan de la fase preliminar pasan a la fase de Visión Arquitectónica. En donde se documentan y se analizan desde una perspectiva amplia. Con el objetivo de identificar los recursos necesarios.

    Después de este análisis, pasa a la fase de Arquitectura de negocio. En donde se debe entender el negocio. Es decir, el propósito de la organización. TOGAF propone tres maneras (dominios) que en conjunto revelan ese ideal que persigue la organización.

    • Arquitectura Empresarial: Se centra en el negocio y sus capacidades.
    • Arquitectura de los Sistemas de información: Estudia la empresa basada en los datos, el trabajo con ellos y sus interrelaciones.
    • Arquitectura Tecnológica: Plantea la empresa desde el punto de vista de la tecnología que emplea.

    Un dato importante al trabajar con ADM es que, en sus iteraciones, podemos recortar y conectar a otros nodos para que la arquitectura se adapte a la organización. Lo cual quiere decir que yo puedo pasar por todos o solamente uno de los dominios que se plantearon. No solo en este caso, si no en cualquiera de los nodos que seguiremos explicando.

    Al final del ciclo tenemos Oportunidades y Soluciones. En donde se empieza a evaluar el bloque que necesitamos para responder a el problema que se esta evaluando. Es decir, ya vimos como ese problema o producto impacta en la organización. Ahora es momento de proponer soluciones basado en nuestro repositorio. Ya sea con un bloque existente o con la creación de uno nuevo.

    Una vez se tenga este análisis, se pasará a la Planificación de la migración. En donde se calculan los costes, esfuerzos y recursos que se necesitan para la solución sugerida.

    Una vez se entrega la solución para su desarrollo, el arquitecto pasa a ser el responsable de que se cree y complete la solución. En la fase que se conoce como Gobernanza de la Implementación. Donde debe validar lo que esta ocurriendo durante el desarrollo e implementación de la misma.

    Finalmente se llega a la Gestión de cambio. Donde se evalúa de nuevo la solución. Como se integra a la organización y como se adapta a los nuevos paradigmas a los que se enfrenta la empresa. Si se evidencia que necesita un cambio se vuelve a iterar sobre el proceso para hacer los respectivos ajustes.

    Algo importante a notar, es que en el centro tenemos la Gestión de Requisitos. Lo que quiere decir que en todo momento se debe trabajar con estos en mente y como no, con las personas que proveen y trabajan para solventarlos.

    Construyendo bloques

    Cuando se esta creando la arquitectura empresarial, es muy importante que los bloques que se crean sean relevantes para la organización y sobre todo para los interesados en el proceso que representa ese bloque. Cuando esto no sucede. Es decir, se crea el bloque, pero tiene información irrelevante o no se ajusta a la necesidad se le denomina como Wall-Ware. Para evitar esto, se debe contar con la cantidad de información justa e indicada. Siempre teniendo en mente que el propósito de la mayoría de las organizaciones es generar una ganancia. El tiempo y otros recursos que se emplean para procesar estos bloques generan un costo. Por eso es muy importante evaluar la definición de los bloques, tanto su funcionalidad como los recursos que recibe y provee.

    Para iniciar creamos una vista del bloque, es decir algo visual que los interesados puedan identificar como la solución a su problema. Cada interesado puede dar su punto de vista y opinión al respecto. Esto se almacena en una biblioteca de puntos de vista. Y es en realidad solo una forma de almacenar las preocupaciones (requisitos) de los interesados, para a partir de ahí generar una maquetación.

    TOGAF propone diversas herramientas empresariales para luego interpretar esa información. Por ejemplo, en base a la descripción de los puntos de vista le propone generar ciertos catálogos y documentos con los que luego se puede trabajar fácilmente.

    TOGAF también implementa un módulo enfocado a la planificación basado en la capacidad. Es decir, el resultado de la utilización de los recursos. A pequeña escala, se le denomina función. Que es propiamente el trabajado con algunos recursos específicos.

    Luego varias funciones se empaquetan y se convierten en un proceso. Donde ya se define un flujo, reglas y decisiones a tomar. Podríamos traducir el proceso como el manual y la función como el resultado.

    Al seguir los pasos que indica el proceso siempre nos debería resultar el mismo producto. Ya sea bueno o malo, dependiendo del punto de vista, el cual es proporcionado por las personas que participan.

    En nuestro caso genera un bloque. Que debería estar conformado por otros bloques. Es decir que yo podría seguir construyendo hasta llegar a la totalidad de la organización. Y cada integrante participa con el modelamiento y trabajo de cierta sección de bloques, en mayor o menor medida, dependiendo de sus funciones. Por lo que los bloques deben ser altamente reusables y poder crecer con ayuda de otros bloques. Esto garantiza que mas adelante la organización se podría adaptar a los cambios e inclusive a una nueva visión. A esto se le llama madurez.

  • Aplicación de una sola página

    Aplicación de una sola página

    Una aplicación de una sola página, como su nombre lo indica, es un sitio donde su frontend se construye dinámicamente desde javascript en una única página, pero se hace de tal manera que cada uno de sus componentes o módulos se va cargando progresivamente, de esta manera se logra brindar una experiencia mucho más fluida. Veamos un ejemplo mas grafico para ver como funciona una petición(request) de una página comúnmente.

    Proceso de petición de una pagina. En paginas convencionales cada vez que hacemos una petición el servidor nos responde con todo el contenido y refresca la pagina.

    Imaginemos que entramos, por ejemplo, a una página construida en PHP (la web suele estar repleta de estos sitios). Nuestra carga inicial es cuando hacemos la petición al dominio, por ejemplo jhontona.com, el DNS se nos redirecciona al servidor que se encargará de brindarnos el contenido que solicitamos, suele ser común los .html (contenido), .css (estilos) y .js (funcionalidad). El problema es que cada vez que se procesa una nueva petición, por ejemplo al enviar un formulario, el cliente requiere hacer una nueva llamada al servidor, este la procesa y reenvía todo el contenido mas la respuesta para el usuario. Esto genera que el sitio se recargue en su totalidad.

    En sus inicios la web eran solo bloques de texto, pero ahora tenemos imagen y video, el cual es demasiado costoso de enviar, sobre todo en redes lentas; para apalear un poco este problema los navegadores guardan en memoria (cache) los archivos más comunes (los mismos que miramos antes) con el objetivo de eliminar de la descarga esos archivos que previamente se habían cargado.

    Las aplicaciones de una sola página (SPA) justamente se aprovechan de este sistema, enviando solamente el contenido que el usuario requiere en ese momento. Veamos como lo hace.

    En nuestro esquema parece que no cambia mucho pero en la pagina esto tiene una gran repercusión, ya que en múltiples peticiones al servidor solo se trae la información que se necesita en ese momento y esto se agradece mucho sobre todo en redes móviles, ya que hacen que nuestras paginas carguen mucho más rápido al solo traer lo que necesitamos para una carga inicial y a partir de esta vamos trayendo los fragmentos necesarios a medida que el usuario navega en nuestro sitio.

    Para crear este tipo de sitios de una sola página se suele trabajar con javascript, este justamente se ejecuta en el cliente y se encarga de hacer las peticiones de manera incremental, podríamos por ejemplo con javascript puro ir haciendo nuestras peticiones a un servicio he ir mostrando la información como deseamos; pero afortunadamente no toca iniciar desde cero, entre los mas reconocidos frameworks tenemos Angular, React y VUE. Todos estos frameworks tienen el mismo objetivo, construir sitios SPA, pero utilizan diferentes enfoques. En un próximo post veremos por que usar Angular y sus características.

  • PHP y MySQL

    PHP y MySQL

    PHP y MySQL (Del que ahora deriva MariaDB) son una combinación ganadora, por que es muy fácil implementarlo y desarrollar con estas dos herramientas.

    Para continuar con nuestro curso vamos a realizar una conexión a la base de datos y hacer unas pruebas sencillas, la conexión va a ser directa, sin uso de interfaces ni temas complejos, estos los veremos mas adelante.

    Conectando PHP con MySQL

    En este momento la ultima versión de PHP es la 7.2.6, así que la sintaxis que usare será para la versión 5.5 en adelante, esto lo aclaro por que si tienes una versión antigua debes usar la función mysql_connect, yo en este caso usare la clase mysqli. Si deseas saber que versión de php tienes, puedes usar la instrucción echo phpinfo(); dentro de un documento php, así te mostrara toda la información de PHP con la que cuenta tu equipo o servidor.

    Vamos a crear un archivo, en este caso lo llame 01.ConexionMySQL.php

    <!doctype html>
<html lang="es">
    <head>
        <meta charset="utf-8">
        <title>PHP y MySQL</title>
        <meta name="description" content="PHP y MySQL template">
        <meta name="author" content="Jhontona.com">
    </head>
    <body>
        <?php
            $host = "localhost";
            $user = "jhontona";
            $password = "phpcurso1";
            $database = "test";
            $mysqli = new mysqli($host, $user, $password, $database);

            if ($mysqli->connect_errno) {
                echo "Fallo al conectar a MySQL: (" . $mysqli->connect_errno . ") " . $mysqli->connect_error;
            }
            echo $mysqli->host_info . "\";

        ?>
    </body>
</html>

    Ahora es momento de revisar el código, voy a enfocarme de la línea 15 a la 24, ya que es nuestro código PHP, en las primeras líneas(de la 15 a la 18) estamos declarando variables.

    Variables en PHP

    Si recordamos el anterior post, decíamos que PHP es un lenguaje interpretado y de tipado dinámico, por lo que no es necesario mencionar a que tipo de variable corresponde cada una, es decir, que tipo de valores puede almacenar (Si quieres profundizar en tipados revisa este post).

    Como podemos ver en el anterior ejemplo una variable en PHP se inicializa con el signo $ y seguido el nombre de la variable.

    Después, estamos asignándole un valor a cada variable, con el signo = y luego le pasamos un valor, en nuestro anterior ejemplo todos los valores son de tipo string(texto), pero puede ser de diferentes tipos, y como lo indicamos, puede tomar en el transcurso de la ejecución cualquier otro tipo, vamos a ejemplificar esto con otro pequeño fragmento de código.

     

    Ejemplo de variable con varios tipos

    <?php

/*Tipos de variables*/
$mivariable = "string"; //Texto
$mivariable = 4; //Numero
$mivariable = array(); //Matriz
$mivariable = 5.32; //Numero decimal
$mivariable = true; //Booleano (verdadero o falso)

?>

    En el anterior ejemplo podemos ver como una misma variable puede tomar varios valores de diferentes tipos, si quieres conocer todos los tipos que maneja PHP te dejo el enlace.

    También otra cosa importante es la inclusión de comentarios en el código.
    Adrede incluí los dos tipos de comentarios que maneja PHP, el comentario de varias líneas, que se inicia con /* y se debe cerrar con */, y el comentario de una sola línea //, que solo necesita la apertura, ya que se finaliza automáticamente con el salto de línea.

    Ya que conocemos la teoría sobre variables en PHP continuemos revisando el código.

    En la línea 20 se declara otra variable, y se le asigna una instancia de la clase mysqli, para poder crear un nuevo objeto de este tipo se le pasan unos valores, que en este caso son los valores que almacenamos en las variables antes declaradas. Estos valores corresponden a los datos de conexión a la base de datos. Si quieres conocer mas sobre objetos, clases y conceptos relacionados a la programación orientada a objetos te recomiendo leer este post.

    En PHP para crear una nueva instancia de una objeto se utiliza la sentencia new, que precisamente indica que es un nuevo objeto de un tipo de clase determinado. En la línea 21 estamos utilizando la condición if(si) para preguntar si ocurrió algún error en la conexión. (Si necesitas saber mas sobre las estructuras básicas de programación te dejo este post). Bien, dentro de este condicional tenemos la variable $mysqli que si recordamos era un objeto de clase mysqli, y al ser de este tipo tiene todos sus atributos y métodos(funciones), uno de estos atributos es connect_errno que nos indica si la conexión fue exitosa o no, es decir es una variable de tipo booleano. Si prestamos atención, podemos ver que para acceder a un atributo estamos utilizando los símbolos -> que le indica al interprete de PHP que es un atributo de un objeto.

    La línea 22 se ejecuta si hubo un error, y lo que hace es imprimir el error. Algo nuevo en esta línea es el uso del punto(.) que en PHP es el símbolo para concatenar, es decir, unir dos cadenas de texto.

    Y finalmente en la línea 24 imprimimos el valor de otro atributo de la clase mysqli. Tal vez eso halla sido un poco complejo, pero no te angusties en el transcurso del curso y de la practica entenderás los conceptos, este ejemplo lo saque directamente de la documentación de PHP por lo que te aconsejo que siempre en tus desarrollos y practicas revises el sitio para verificar la sintaxis y el uso de las funciones. También te dejo el link del archivo de esta clase en Github y si tienes dudas o algún comentario por favor déjalo, así podemos seguir aprendiendo todos.

  • Código limpio – Haciendo código bien y bonito

    Código limpio – Haciendo código bien y bonito

    Cuando estas aprendiendo a programar te enfocas primero en la lógica, luego en el lenguaje y rara vez nos detenemos a pensar en la forma de hacerlo, es decir, como pasamos de la lógica al lenguaje. Es justamente el turno de revisar como debemos escribir este código, ver buenas practicas y como aplicarlas. El contenido de este post esta basado en el libro Código limpio(Clean code) de Robert C. Martin y también en mi experiencia. Lo estructurare tal cual esta dividido en el libro.

    ¿Por qué hacer código limpio?

    Si estas leyendo este post, o estas interesado en el libro, eres programador o futuro programador, y crees en la necesidad de hacer un código elegante. No por simple capricho o ego, si no por que a medida que te internas mas en el mundo del desarrollo de software, puedes ver sus falencias. Mientras estaba en el primer semestre de mi especialización en Ingeniería de software, tocamos el origen de este problema, se remonta a la conferencia de Crisis del software que se celebro en 1968, esta se llevo a cabo con el objetivo de identificar causas y dar posibles soluciones a los problemas con los que se venia trabajando el software y aun en la actualidad continua. Se identificaron muchas causas y se dijo que la calidad de un producto se mide por su funcionamiento. En aquel entonces sirvió, y esto dio paso a definición de metodologías, arquitecturas y patrones de desarrollo de software, pero gracias a estas nuevas proposiciones se descubrieron nuevos problemas que estaban ocultos ¿Por qué te cuento esto?, por una sencilla razón, “Aquel que no conoce la historia, está condenado a repetirla“. Miremos ahora el problema que nos concierne, y que actualmente no es tratado como un problema real, si no como un añadido, ya que son pocos los que trabajan con estas pautas de código limpio. La pregunta mas lógica a continuación sería ¿por qué es un problema no trabajar con código limpio? La respuesta te la dará la experiencia, en mi caso llevo varios años trabajando y he sido parte de fracasos de software precisamente por este detallito, se hace el código, y por las prisas, trabajo represado y falta de compromiso como profesional se hace el desarrollo a la carrera, y esto no es el problema. El problema no es correr, el problema es salirse de la pista para coger un atajo. Por ejemplo, inicias con un proyecto, tienes todas las ganas de hacerlo bien, es tu bebe y debes mimarlo, hacerlo fuerte y también sentirte orgulloso de el, pero te piden algo nuevo, o cambian las fechas de entrega y debes correr, ejercen presión sobre ti para generar una entrega rápida y optas por hacerlo rápido y olvidarte de ciertos estándares o la forma de trabajo con la que venias usando. Luego con el tiempo esto se transforma en una bola de nieve, va creciendo con cada iteración que se da, y esto es un grave problema, por que llega un punto en el que el código se vuelve muy difícil de mantener, las personas que lo trabajan se aburren y lo dejan de lado, Se convierte en un ciclo donde un error genera otro error, hasta el punto en que se piensa en reestructurar toda la aplicación, para lastimosamente luego cometer los mismos errores.

    Los lenguajes de programación han ido avanzando, encontramos desde lenguaje de maquina a lenguaje de alto nivel, que se acercan lo mas que pueden al lenguaje natural, pero si el programador es incapaz de expresarse correctamente su código estará lleno de errores, y los errores llaman mas errores. Otro caso, también podría ser que hagamos el código de afán y pospongamos el refinamiento, aquí entra la Ley de LeBlanc, que dice que después es igual a nunca, por eso, lo correcto es desde el inicio fijarnos un camino y seguir las buenas practicas y estándares. Debemos convertirnos en defensores del código elegante, del profesionalismo, eso hace parte de nuestra ética como ingenieros.

    El código limpio debe cumplir ciertas características, ser de fácil lectura, eficiente, concreto, legible, mejora con cada iteración y no contiene duplicados. En el desarrollo de este post entenderás estos principios mas a fondo.

    Nombres con sentido

    En la programación todo el tiempo estamos utilizando nombres, para las variables, funciones, clases. Por lo que la primera regla para un código limpio es crear correctamente estos nombres.

    Dicientes

    Esto se refiere a la capacidad de expresar su propósito, dejar de lado aquellas variables de unas cuantas letras que no expresaban absolutamente nada.

     

    Ejemplo de nombre de variable

    //Incorecto
int a = 12;
//Correcto
int cantidadMeses = 12;

    Diferentes

    Los nombres de las variables, métodos, clases, etc. deben ser diferentes entre si y expresar correctamente su funcionamiento. Por ejemplo, supongamos que tenemos dos funciones, una se llama traerUsuario y la otra getUsuario. Esto nos puede llevar a una confusión y a perder tiempo revisando el código de cada una de estas funciones para verificar cual es la que necesitamos. Esto se puede evitar asignando nombres claros y diferentes.

    No redundantes

    Esto se refiere a no repetir las mismas palabras dentro de un nombre, ya que podemos confundir al lector. También lo podemos aplicar a no repetir los tipos de datos. Miremos el siguiente ejemplo:

    Redundancia en los nombres

    string nombreString = "";

    La palabra string dentro del nombre esta de mas, y si es necesario especificar el tipo de dato, se aconseja que sean palabras diferentes a las reservadas por el lenguaje.

    Pronunciación

    Un dato que me pareció curioso y válido, es que pasamos la mayoría del tiempo de codificación, no escribiendo código, por el contrario, la mayor parte esta dedicada a la lectura del código. Por este motivo tanto énfasis en hacer un código limpio y legible, por eso cada bloque de código se debe poder pronunciar y acercarse lo mas que se pueda al lenguaje natural, claro esta sin excesos, tampoco podemos crear todo un párrafo como nombre de algún objeto, siempre hay que tener buen criterio y la experiencia y uso de estas técnicas son las que nos ayudaran a mejorar.

    Codificaciones

    Debemos evitar el uso de siglas o codificaciones propias, ya que lo que puede ser claro o evidente para mi, puede que no lo sea para los demás. Si se desea usar algún tipo de convención, sigla o codificación especial debe ser consensuada y compartida a cada integrante del equipo.

     

    Para concluir este segmento y continuar revisando los principios del código limpio concluiremos diciendo que los nombres deben tener sentido dentro de su contexto, ser concretos, claros. Podríamos hacer una ejercicio, es tedioso y poco productivo, pero es muy educativo; podemos pasarla la lista de nombres a otra persona y si logra armar el contexto(clase) a partir de nuestros nombres de variables y funciones hemos realizado un excelente trabajo.

    Algunas recomendaciones para nombrar clases es no usar verbos, por el contrario en las funciones se recomienda siempre usarlos. Y por ultimo, aunque parezca contradictorio, intenta hacer nombres cortos.

  • Introducción a PHP

    Introducción a PHP

    Este es el primer post de un muy prometido curso sobre PHP, los talleres los hare en vídeos que podrás encontrar al final de cada post, pero en cada uno de estos tendrás acceso al repositorio de GitHub y a la tan necesaria información teórica. Bueno y sin mas parafernalia entremos en materia.

    ¿Qué es PHP?”

    PHP es un lenguaje de programación interpretado, que se usa junto con el código HTML para crear paginas web, que es altamente famoso por contar con una gran cantidad de soporte y documentación.

    Para comenzar a utilizar PHP se necesita de un servidor web que le de soporte, recomiendo para desarrollo usar XAMPP, siempre he trabajado con este y nunca he tenido un problema grave. No voy a explicar la instalación ya que se me hace muy sencilla, solo debes tener cuidado que al momento de arrancar el Apache(Es el servidor que soporta PHP) el puerto este libre, por defecto toma el 80 y a veces puede dar conflicto, sobre todo si tienes Skype. Cierra estos programas o configura Apache para que inicie en otro puerto. Al igual si tienes dudas puedes dejarla en los comentarios.
    Continuando, una vez tenemos el servidor montado ya podemos trabajar con PHP, creando archivos con la extensión .php.

    ¿Porqué usar PHP?

    En otro post hablé sobre las ventajas de los lenguajes de tipado dinámico, y además de estas ventajas hay otras mas que pasare a mencionar.

    • Yo diría que la mayor ventaja es su alta difusión, casi cualquier servidor de hosting ofrece por defecto un servidor para PHP.
    • Otra ventaja es que para usarlo no necesitas licencias, y aprenderlo es muy fácil ya que tiene mucha, pero mucha documentación.
    • Es un lenguaje multiplataforma, lo puedes instalar, usar y aprender en cualquier entorno.
    • Junto con MySQL son la pareja mas conocida en la web.
    • Es de código abierto. Puedes formar parte del desarrollo de este lenguaje.

    Hola mundo

    Como mencione anteriormente, yo uso XAMPP, así que los ejemplos y capturas de pantalla que haga estarán sobre este servidor.
    Crearé un archivo llamado index.php con el siguiente código:

    <span>Hola mundo</span>

    Este es simplemente código HTML, pero funciona, ya que como lo había mencionado PHP es interpretado, es mas, en algunas fuentes lo llaman empotrado, ya que hace uso de la semántica de HTML, aunque PHP quiere dejar de lado esto, y que se trabaje de una forma orientada a objetos para olvidarnos de aquellos tiempos del código espagueti, que fue como en un principio inicio y se hizo popular PHP. Así que vamos a cambiar solo un poco ese código. Vamos a agregarle las etiquetas de inicio y cierre de PHP junto con la primera instrucción que veremos.

    <?php
echo "<span>Hola mundo</span>";
?>

    ¿Qué podemos ver de las líneas anteriores de código? Primero conocemos la etiqueta de apertura de PHP, y en la tercera lineá la etiqueta de cierre, esto le indica al interprete que todo el contenido que este dentro de estas etiquetas se entenderá como código PHP.
    Ahora en la segunda lineá vemos nuestra primera función de PHP, bueno en realidad no es una función, es una instrucción propia del lenguaje. Y esta instrucción lo que hace es mostrar una cadena de texto, en este caso le estamos pasando nuestro “Hola Mundo” y finalizamos nuestra lineá con el caracter ; el cual es muy importante, ya que finaliza nuestra lineá y en este caso también la instrucción echo.
    Hay que recordar que PHP nació como un lenguaje estructurado, para ser usado junto con HTML, gracias a esto se popularizo, pero esto también le creo una “Época oscura”, donde casi ni se podía diferenciar el código de script y de HTML, era un caos hacer mantenimiento, por este motivo yo personalmente no aconsejo usar etiquetas HTML dentro del código PHP, mas adelante te enseñare formas elegantes de hacerlo. Por ahora solo quería comentarles que se puede hacer.
    PHP es interpretado lineá a lineá, por lo que es muy importante siempre finalizarlas con ;(punto y coma).

    Vamos a dejar por aquí este post, recuerda que este es el primero del curso de PHP, y por cierto te dejo el enlace a la documentación oficial de PHP. Deja tus comentarios, inquietudes y sugerencias.

¡Hola a todos los entusiastas de la tecnología! Quería informarles que en mi blog utilizamos cookies para mejorar la experiencia de usuario. Estas pequeñas herramientas nos ayudan a personalizar el contenido y ofrecer funciones específicas. Al continuar explorando el sitio, aceptas nuestro uso de cookies. Puedes obtener más información sobre cómo las utilizamos en nuestra política de privacidad. ¡Gracias por ser parte de esta comunidad tecnológica! 🍪    Más información
Privacidad