Fechas antes de versión 8 de Java - versión 8 en adelante de Java

TRABAJAR CON FECHAS EN JAVA

La forma clásica de trabajar con fechas en Java es con las clases Date y Calendar. La primera representa un punto cronológico en el tiempo, expresado en milisegundos. La segunda nos ofrece una interfaz más rica con la que poder trabajar con fechas. 

Un ejemplo de uso sería el siguiente:

Calendar calendar = Calendar.getInstance();

// instancia con el tiempo local

calendar.set(Calendar.YEAR, 1990);

calendar.set(Calendar.MONTH, 3);

calendar.set(Calendar.DATE, 10);

calendar.set(Calendar.HOUR_OF_DAY, 15);

calendar.set(Calendar.MiNUTE, 32);

Date date = calendar.getTime();

// convertimos de Calendar a Date

Sin embargo, esta API tiene algunos problemas. No tiene un diseño demasiado bueno, puesto que no pueden utilizarse fechas y horas por separado, y no thread safe, lo que puedo ocasionar problemas de concurrencia. Por eso, Java 8 introdujo una nueva API que ofrecía fechas inmutables, adaptadas a diferentes calendarios y con un diseño mejorado que nos ofrece métodos factoría. Podemos encontrar esta API en el paquete java.time.

Las clases base son LocalTime, LocalDate y LocalDateTime.

LocalDateTime timepoint = LocalDateTime.now();

// Fecha y hora

LocalDate date = LocalDate.of(2020, Month.JULY, 27);

// Obtenemos la fecha indicada

LocalTime.of(17, 30);

// obtenemos la hora indicada

LocalTime.parse("17:30:00");

// Otra forma para la hora 

// Usamos la convención estándar parar get

Month month = timepoint.getMonth();

int day = timepoint(getDayOfMonth();

// Son inmutables, así que cambiar el valor retorna un objeto

LocalDateTime happyTwenties = timepoint.withYear(1920)

.withMonth(Month.January)

.withDayOfMonth(1)

.plusWeeks(3);

El paquete también ofrece otras clases adicionales, como Period o Duration, que sirven para representar laspos de tiempos, algo que no estaba soportado por Date y Calendar. Además, existen otras herramientas y conceptos más avanzados que puedes investigar si estás interesado.

Formateado de texto

Si tratamos de sacar por pantalla el valor de números decimales o fechas, podemos encontrarnos con que el resultado no es demasiado legible ni atractivo. Java nos ofrece algunas clases para trabajar con el formato del texto en el paquete java.text. Veamos un ejemplo a continuación:

Date date = new Date(); // Fecha Actual

SimpleDateFormat sdf = new SimpleDateFormat("dd-MM-yyyy");

String date = sdf.format(date);











PROGRAMACIÓN REACTIVA

 

Programación reactiva

No debemos confundir programación reactiva con sistemas reactivos. Los sistemas reactivos están definidos en el Manifiesto Reactivo.

Al igual que el paradigma anterior la programación reactiva está basada en el desarrollo declarativo. Se enfoca en flujos (streams) de datos asíncronos y en un modelo basado en eventos, permitiendo la propagación de los cambios de foma automática, donde la información se envía al consumidor a medida que está disponible. Esto permite realizar tareas en paralelo no bloqueantes que ofrecen una mejor experiencia al usuario.

Los lenguajes que soportan la programación reactiva suelen tener su propia librería con una serie de funciones para crear, transfomar, combinar o filtrar los streams. Un stream es una secuencia de eventos (pudiendo ser de cualquier tipo) ordenados en el tiempo que puede devolver tres tipos de resultados: un valor, un error o una señal de completado. Estos resultados generados se emiten de forma asíncrona a través de una función que es ejecutada por el suscriptor u observador. Lo mencionado es, básicamente, el patrón Observer, ya que tenemos un sujeto (el stream) que está siendo observado por las funciones mencionadas (observadores o suscriptores).

OTRA DE KEITH - POR SUPUESTO URBAN


     

                GOD BLESS YOU URBAN

QUE ES LA INYECCIÓN DE DEPENDENCIAS O INVERSIÓN DE CONTROL - ENTRADA CORTA

 

Inyección de dependencias

La inyección de dependencias es uno de los pilares fundamentales en que se basa Spring. Aunque no fue el primer framework que usaba este concepto, sí fue el que lo popularizó en el mundo Java enterprise. Durante mucho tiempo era una de las diferencias más destacadas entre el "enfoque Spring" y el JavaEE estándar. En este último, cuando un objeto necesitaba de otro o de un recurso debía localizarlo él mismo mediante el API JNDI. No obstante, en la actualidad, como ya se ha visto en otros módulos, el estándar ha ido incorporando la inyección de dependencias en múltiples tecnologías (JPA, JSF, web...).

JAVASCRIPT - GETTERS Y SETTERS EN ES5

Propiedades con get y set en Javascript

Conoce los getters y setters en Javascript, llamados accessors, que permiten crear lo que se conoce propiedades computadas cuyo valor se extrae de métodos declarados con get y set.

En este artículo vamos a conocer los getters y los setters de Javascript, una herramienta disponible en objetos de Javascript, que existe en el lenguaje desde hace bastante tiempo y que muchos desconocen. Son los getters y los setters con get y set en los objetos o clases de Javascript.

En principio, esta utilidad se encuentra disponible en navegadores muy antiguos, pues forma parte de ES5, así que la puedes usar con tranquilidad. Si conoces la programación orientada a objetos, y conceptos como encapsulación, tendrá más sentido para ti, pero si no es así tampoco te viene mal echarle un vistazo, para cuando encuentres código que haga uso de esta construcción del lenguaje, que sepas de qué se trata.

Qué es un getter o un setter

Para los que no han oído hablar sobre éstos, los getters y los setters son construcciones habituales de los objetos que permiten acceder a valores o propiedades, sin revelar la forma de implemetación de las clases. En pocas palabras, permiten encapsular los objetos y evitar mantenimiento de las aplicaciones cuando la forma de implementar esos objetos cambia.

Utilidad aparte, en la práctica son simplemente métodos que te permie acceder a datos de los objetos, para leerlos o asignar nuevos valores. El setter lo que hace es asignar un valor y el getter se encarga de recibir un valor.

Sin embargo, los getters y los setters de los que vamos a hablar en Javascript son un poco distintos de los tradicionales.

También llamados accessors

Los get y los set de Javascript se denominan técnicamente accessors o también "Object Accessors". Seguramente encontrarás esta terminología en documentación diversa de Javascript, por lo que deberías conocer el término.

Otra manera de denominar este tipo de miembros de objetos es con el nombre de propiedades computadas o "computed properties" en inglés.

Propiedades computadas de objetos Javascript

Los get y los set de los que nos ocupamos en este artículo son útiles básicamente para realizar el acceso a propiedades de los objetos que son resultado de computar otras propiedades existentes.

El ejemplo más claro de setters y getters en Javascript lo tenemos con el objeto persona. Est objeto podría tener un par de propiedades como el "nombre" y los "apellidos". Además podríamos desear conocer el nombre completo, pero realmente éste no sería realmente una propiedad nueva del objeto, sino el resultado de un cómputo de concatenación entre el nombre y los apellidos que tenemos en las dos propiedades anteriores.

Es decir, "nombreCompleto" podría ser una propiedad computada. En los lenguajes tradicionales, incluso en Javascript si lo deseamos, podríamos implementar ese valor computado con un método como este:

Javascript si lo deseamos, podríamos implementar ese valor computado con un método, como este:

var persona = {

    nombre: 'Miguel Angel',

    apellidos: 'Alvarez Sánchez',

    getNombreCompleto: function() {

        return this.nombre + ' ' + this.apellidos;

    }

}

Nota: El código anterior, y el que verás en el resto de este artículo, está basado en objetos literales de Javascript. Lo normal sería usar clases, pero mantendremos este estilo de codificación ya que las clases se agregaron en el lenguaje en la versión ES6 y en este manual estamos tratando la versión tradicional de Javascript (ES5).

Podríamos acceder al nombre completo con este código:

var nombreCompletoPersona = persona.getNombreCompleto();

Sin embargo, con las construcciones get y set de Javascript la forma de definir este código cambia un poco. Mediante la palabra reservada "get" puedo definir una función que se encarga de realizar el cómputo. Aquello que devuelve la función será el valor de la propiedad computada. El código nos quería más o menos así:

var persona = {

    nombre: 'Miguel Angel',

    apellidos: 'Alvarez Sánchez',

    get nombreCompleto() {

        return this.nombre + ' ' + this.apellidos;

    }

}

La novedad es el uso de la construcción "get" en el código anterior, que nos sirve para definir una especie de método. Sin embargo, no es un método tradicional, sino más bien una propiedad computada, es decir, una propiedad de un objeto que para resolver su valor tiene que ejecutar una función. Nos debería quedar claro este punto con el código siguiente, en el que usamos esa propiedad computada "nombreCompleto".

var nombreCompletoPersona = persona.nombreCompleto;

Ahora en la variable "nombreCompletoPersona" tenemos el valor del nombre y apellidos concatenados. Fíjate para acceder a ese "getter" usamos "persona.nombreCompleto", que es como si estuviéramos accediendo a una propiedad convencional aunque internamente en nuestro objeto no existe tal propiedad, sino que se realiza un cómputo para poder evaluarla.





PRIMERA ENTRADA SOBRE FRONT - ANGULAR - COMUNICACIÓN PADRE - HIJO Y VICEVERSA

 

El siguiente ejercicio propone un proyecto muy simple en el que un componente padre se encarga de recoger dos valores que le pasa al hijo para realizar una operación sencilla (suma, resta, multiplicación y división) y, una vez obtenido el resultado, el mismo se devuelve al padre para que este se muestre en su vista.

Crear prototipo comBC -> ng new comBC

Crear componente compo1 -> ng g c compo1

Abrimos la aplicación con nuestro editor y dejamos en app.component.html el siguiente contenido:

<div class="padre">

<table border="1">

    <th coldpan="2" style="text-align: center">Padre</th>

    <tr>

        <td>Valor1</td>

        <td><input class="form-control" [(ngModel)]="valor1"></td>

    </tr>

    <tr>

        <td>Valor2</td>

        <td><input class="form-control" [(ngModel)]="valor2"</td>

    </tr>

    <tr>

        <td>Resultado: </td>

        <td><b>{{ resultadoP }}</b></td>

    </tr>

<table>

</div>

<app-compo1 [valor1]="valor1" [valor2]="valor2" (envRes)="captaResultado($event)">

</app-compo1>

En app.component.ts modificaremos la clase AppComponent para que tenga lo siguiente:

export class AppComponent {

    valor1: string = '10';

    valor2: string = '20';

    resultadoP: number;

    captaResultado(event) {

        this.resultadoP = event;

    }

}


Ahora, modificaremos compo1.component.html para añadir los botones con las operaciones:

<div class="hijo">

<table border="1">

<th colspan="4" style="text-align: center">Hijo</th>

<tr>

<td><button class="tamB" (click)="suma()">+</button></td>

<td><button class="tamB" (click)="suma()">+</button></td>

<td><button class="tamB" (click)="suma()">+</button></td>

<td><button class="tamB" (click)="suma()">+</button></td>

</tr>

</table>

</div>


Seguidamente, modificamos compo1.component.ts para que el import existente al inicio del fichero contenga lo siguiente:

import { Component, Input, Output, EventEmitter, AfterContentChecked } from '@angular/core';

También modificaremos la clase Compo1Comonent con el siguiente contenido:

export class Compo1Component {

@Input()

    valor1: string;

    @Input()

    valor2: string;

    aux1: number;

    aux2: number;

    @Output()

    envRes: EventEmitter<number> = new EventEmitter<number>();

    ngAfterContentChecked() {

        this.aux1 = parseFloat(this.valor1);

        this.aux2 = parseFloat(this.valor2);

    }


    suma() {

        this.envRes.emit(this.aux1 + this.aux2);

    }

   resta() {

       this.envRes.emit(this.aux1 - this.aux2);

   }


   multiplica() {

       this.envRes.emit(this.aux1 * this.aux2);

   }


   divide() {

     this.envRes.emit(this.aux1 / this.aux2);

  }

}


Por último, modificaremos el archivo styles.css con lo siguiente:

div {

    width: 250px;

    padding: 20px;

    display: block;

    text-align: center;

}

.padre {

    background: #abe4b8;

}

.hijo {

    background: #5af0f0;

}

.tamB {

    height: 53px;

    width: 53px;

    font-size: 20px;

}

Un ejemplo sencillo de como es la comunicación entre componentes en Angular y utilizando TypeScript, por supuesto.





KEITH URBAN BRUTAL

 


Keith Urban esta es puro espectáculo 

SCRUM RESUMIDO

Scrum

El método SCRUM, define un marco para la realización de proyectos complejos. Inicialmente planeado para el desarrollo de proyectos de tipo "Software", este método se puede aplicar a cualquier tipo de proyecto, desde el más simple al más innovador, y de una manera muy simple.

Esta metodología permite adaptarse rápidamente a cambios de un cliente a frecuencia regular. Cuando una iteración finaliza, el equipo y el cliente vuelven a evaluar las especificaciones del software.

¿Por qué Scrum?

Antes, el cliente no veía la evolución del trabajo y apenas participaba en la ejecución de su proyecto. De hecho, no pudo comenzar a hacer pruebas antes de que todo estuviera casi terminado. Por otro lado, en Scrum, el cliente está más involucrado en el proceso porque un proyecto contiene varios entregables que debe aprobar. Con cada entregable, las funcionalidades estan en constante mejora y el cliente ve regularmente la evolución del trabajo y si algo no le conviene, es más fácil ajutarlo para satisfacer sus necesidades. Así que Scrum se trata esencialmente de optimizar la previsibilidad de un proyecto y controlar mejor los riesgos.

Scrum se basa en la división de proyectos en iteraciones que todavía se llaman "Sprints". Un Sprint es un perído durante el cual se realiza una funcionalidad (o incremento del proyecto).

El método Scrum define tres roles para un proyecto:

1.- Product Owner: Este es el representante oficial del cliente dentro de un proyecto de Scrum. Define las necesidades del producto y escribe especificaciones. También es responsable de definir y priorizar historias de usuarios para cada sprint.

2.- Scrum Master: Es una persona responsable de garantizar la aplicación del método y el respeto de sus objetivos. Este no es un gerente de proyecto, sino una persona responsable de eliminar cualquier obstáculo qeu impida el avance del equipo y del proyecto durante los diferentes sprints.

3.- Team Members: Estas son las personas responsables del sprint y un producto que se puede usar en el sprint. Pueden ser desarrolladores, arquitectos, personas a cargo de hacer pruebas funcionales.

Puede tener una duración que generalmente varía entre dos semanas y un mes. Esta corta duración hace posible entregar rapidamente al propietario del producto un incremento de software con el mayor valor de negocio. El software entregado es valioso para el propietario del producto, ya que las características desarrolladas son las que tienen la más alta prioridad, las que se encuentran en la parte superior del folleto del producto. Otra ventaja de la corta duración de las iteraciones es permitir al propietario del producto modificar las prioridades de las funcionalidades solicitadas a medida que avanza el proyecto de desarrollo. De hecho, si desea agregar características, estos se tendrán potencialmente en cuenta durante la próxima iteración. Al inal de cada sprint, los miembros del equipo obteien un producto parcial potencialmente entregable y los comentarios recopilados ajustan la acumulación de pedidos par el próximo sprint. En sí mismo, Scrum solo siguiere tres hitos: Spring Plaining, Daily Scrum y Sprint Review. Durante estos últimos, se producen artefactos de "gestión": la acumulación de productos, el registro de iteraciones.

Fuente: Un libro sobre Spring Batch que estaba en la red.


Ejemplo Fechas a partir de Versión 8 de Java - paquete java.time

 Ejemplo Fechas de un instante dado a otro instante dado 



chorradita del día... un saludo a todos... 

ARQUITECTURA DE MICROSERVICIOS

PATRÓN DE ARQUITECTURA DE MICROSERVICIOS

El patrón de Arquitectura de microservicios tiene una serie de de ventajas importantes. En primer lugar, trata el problema de la complejidad y la adaptación a las nuevas tecnologías. Descompone lo que de otro modo sería una aplicación monolítica enorme en un conjunto de servicios. Si bien la cantidad total de funcionalidades es la misma, la aplicación se ha desglosado en un conjunto de servicios asequibles donde cada uno se ocupa de una única funcionalidad.

El patrón de Arquiectura de microservicios obliga a un nivel de modularidad que en la práctica es extremadamente difícil de conseguir con el código base de una típica aplicación monolítica. En consecuencia, los servicios individuales son mucho más rápidos para desarrollarse, y mucho más fáciles de entender y mantener.

Esta arquitectura también permite que cada servicio pueda ser desarrollado dependiendo de las necesidades de cada desarrollador, con el lenguaje, técnicas, métodos, etc, que él considere oportunas ya que, independientemente de la forma en que se desarrolle este debería poder comunicarse mediante una API. Esta libertad hace que los desarrolladores ya no estén obligados a utilizar las tecnologías, posiblemente obsoletas, que existián al inicio de un nuevo proyecto y puedan empezar a desarrollar el nuevo servicio con tecnologías más actuales. Además, como los servicios son relativamente pequeños, se hace posible reescribir un servicio antiguo para actualizarlo a una tecnología actual.

Los microservicos se pueden desplegar de manera independiente. Los desarrolladores no deben coordinar más el despliegue de cambios locales a su servicio. Este tipo de cambios se pueden implementar tan pronto como se hayan probado. Además, como ya hemos comentado antes, el patrón de Arquitectura de microservicios permite escalar de forma indepdiente cada servicio. Podemos implementar sólo el número de instancias de cada servicio que satisfacen sus restricciones de capacidad y disponibilidad. Además, podemos utiizar los recursos que se adaptan mejor a los requisitos de recursos de un servicio.

Como cualqueir tecnología, todas presentan ventajas e inconvenientes y esta no iba a ser la excepción. Un incoveniente importante de los microservicios es la complejidad que se desprende del hecho de que una aplicación de este tipo es un sistema distribuido. Los desarrolladores deben elegir e implementar un mecanismo de comunicación entre procesos basado en mensajería. Además, también tienen que escribir código para gestionar un error parcial ya qeu el destino de una solicitud puede ser lenta o no disponible. Por lo tanto el sistema de comuicaciones debe ser robusto para garantizar la consistencia de los datos y, en consecuencia, su desarrollo es más complejo que el de una aplicación monolítica.

Una aplicación de microservicios consiste generalmente en un gran número de servicios. Cada servicio tendrá varias instancias de ejecución. Se trata de muchas partes móviles que hay que configurar, desplegar, escalar y controlar. Además, los microservicios son dinámicos y se pueden desplegar en cualquier sistema, cambiar de ubicación a voluntad, replegarse o desplegarse de nuevo, así que hay que tener en cuenta que debemos controlar la ubicación y la disponibilidad en todo momento. Por tanto, también será necesario implemetar un mecanismo de descubrimiento de servicios que permita a un servicio descubrir las ubicaciones (host y puertos) de cualquier otro servicio con el qeu necesite comunicarse. En consecuencia, desplegar con éxito una aplicación de microservicios requiere un mayor control de los métodos de desarrollo por parte de los desarrolladores y un alto nivel de automatización.













GUERRA NUCLEAR, METED CIBER ANTES...

"La tercera Guerra Mundial erá una Ciberguerra"
Así comenzamos este libro... ¿Sera cierto? Jhon McAffe


Lo que si es una realidad según informo en la cumbre de la OTAN en Varsovia 2016 textualmente:
"Habíendose constatado que un ciberataque puede ser tan perjudicial como un ataque convencional, en el campo de la ciberdefensa se han adoptado varias decisiones relevantetes, una de ellas es que.
El ciberepacio se reconoce como un nuevo dominio de las operaciones, al lado de los de tierra , mar, aire y espacio".


La historia de los conflictos bélicos nace con dos dominios: tierra y agua. Cuando aparecen los primeros aviones, se abre un nuevo escenario en los cielos comienza el temida espacio aéreo como una herramienta de combate que desestabilizaba cualquier batalla. Estos tres dominois fueron los dominantes hasta muy pasada la segunda guerra mundial.


Recordemos que luego de esta última, comienza lo que todos conocimos como "guerra fría". Esta etapa histórica es muy importante para lo que trataremos más adelante, pues este libro de guerra se definia por una "capacidad potencial" que tenía un determinado país, y sobre esa base podía disuadir más o menos a sus oponentes. La escalada nuclear llevó a una nueva docrina denominada "Destrucción Mutua Organizada", o también "Mutua Destrucción Asegurada". Como su nombre lo inidica con total claridad, este nuevo escenario nos lleva a un conflicto en el cual su nivel de escalada ocasionaría en el cual su nivel de escalada ocasionaría un nivel de destrucción ocasionaría un nivel de destrucción que afectaría al planeta en su totalidad. Cabe mencionar que esta doctrina está aún vigente y continuado viendo a diario cómo diferentes países siguen avanzando en esta línea, ignorando que es un camino de autodestrucción asegurado...


Estos nuevos misiles, comenzaron a elevar sus alturas de vuelo, llegando a lo que conocemos como espacio. Un hito muy significativo sucedió hace pocos años cuando el gobierno china tuvo la brillante ocurrencia de derribar con un misil satélite de su propio país. Con ello demostró que estaba en capacidad de hacrlo con cualquier otro. A caballo de esto hechos, se acuerda en definir un nuevo dominio de conflicto: el espacio.


Hoy en día, todos sabemos que ese mismo satélite chino, podría haber sido igualmente dejado fuera de combate si comprometemos sus sistemas informáticos o de telecomunicaciones. Esta realdad aplica también a los sistemas de un barco, avión, sistema antiaéreo, de comunicaciones, sistemas C3I (Comando Control Comunicaciones e Informática), un misil, un misil, un tanque, etc.

Fuentes: uno que anda por la web...


SEGUIMOS CON TEORÍA - PRINCIPIOS SOLID - NUEVAS ENTRADAS - NO NOS PASEMOS DE PRAGMÁTICOS

 PRINCIPIOS SOLID

Ahora que conoces los principios básicos de diseño, veamos cinco que se conocen popularmente como los principios SOLID. Robert C. Martin (Uncle Bob) los presento en el libro Desarrollo ágil de software: principios, patrones y prácticas.

SOLID es una regla mnemotécnica para cinco principios de diseño, ideados para hacer que los diseños de software sean más comprensibles, flexibles y fáciles de mantener.

Como con todo en la vida, utilizar estos principios de forma descuidada puede hacer más mal que bien. El costo de aplicar estos principios en la arquitectura de un programa es que puede hacerlo más complicado de lo que debería. Dudo que exista un producto de software exitoso en le que se apliquen todos estos principios al mismo tiempo. Aspirar a estos principios es bueno, pero intenta siempre ser pragmático y no tomes todo lo escrito aquí como un dogma.


Fuente: El mismo libro de la entrada anterior. En breve paso a describir todos los principios lo haré en una sola entrada.

Un saludo a todos.

HERENCIA SI O NO ?

La herencia es probablemente la forma más obvia y sencilla de reutilizar código entre clases. Tienes dos clases con el mismo código. Creas una clase base común para estas dos clases y colocas dentro el código similar. !Pan comido!

Lamentablemente, la herencia tiene sus contras, que a menudo no resultan aparentes hasta que tu programa tiene toneladas de clases y cambiarlo todo resulta muy complicado. Aquí tienes una lista de esos problemas.

1.- Una subclase no puede reducir la interfaz de la superclase. Tienes que implementar todos los métodos abstractos de la clase padre, incluso aunque no vayas a usarlos.

2.- Al sobrescribir métodos debes asegurarte de que el nuevo comportamiento sea compatible con el de base. Es importante porque los objetos de la subclase pueden pasarse a cualquier código que espere objetos de la superclase y no quieres que ese código se rompa.

3.- La herencia rompe la encapsulación de la superclase porque los detalles internos de la clase padre se hacen disponibles para la subclase. Puede darse una situación opuesta en la que un programador hace que una superclase conozca algunos detalles de las subclases, con el objetivo de que las siguientes extensiones sean más sencillas.

4.- Las subclases están fuertemente acopladas a superclases. Cualquier cambio en una superclase puede descomponer la funcionalidad de las subclases.

5.- Intentar reutilizar código mediante la herencia puede conducir a la creación de jerarquías paralelas. Normalmente, la herencia sucede en una única dimensión. Pero cuando hay dos o más dimensiones, debes crear muchas combinaciones de clases, hinchando la jerarquía de clases hasta un tamaño ridículo.

Fuente: Libro Patrones de Diseño de Alexander Shvets.

EJEMPLO DE CÓDIGO PARA DESACOPLAR FUNCIONALIDAD - NIVEL MÉTODOS - EN JAVA


 Error en la nomenclatura del paquete siempre en minúsculas... 

Entrada corta sobre Patrones de Diseño

¿Por qué debería aprender sobre patrones?

La realidad es que podrías trabajar durante años como programador sin conocer un solo patrón. Mucha gente lo hace. Incluso en ese caso, podrías estar implementando patrones sin saberlo. Así que, ¿por qué dedicar tiempo a aprenderlos?

1.- Los patrones de diseño son un juego de herramientas de soluciones comprobadas a problemas habituales en el diseño de software. Incluso aunque nunca te encuentres con estos problemas, conocer los patrones sigue siendo de utilidad, porque te enseña a resolver todo tipo de problemas utiizanod principios del diseño orientado a objetos.

2.- Los patrones de diseño definen un lenguaje común que puedes utilizar con tus compañeros de equipo para comunicaros de forma más eficiente. Podrías decir: "Oh, utiliza un singleton para eso", y todos entenderían la idea de tu sugerencia. No habría necesidad de explicar qué es un singleton si conocen el patrón y su nombre. 

TE VES MUY BIEN USANDO MI CAMISA


 Un poco de música más... always i say... I love country and rock

EL SHOW (FUCK) MAS GRANDE DEL MUNDO


 

BITBUCKET VS JENKINS

Bitbucket vs Jenkins: ¿Cuáles son las diferencias?

Los desarrolladores describen Bitbucket como "Un lugar para planificar proyectos, colaborar en el código, probar e implementar, todo con repositorios privados gratuitos". Bitbucket ofrece a los equipos un lugar para planificar proyectos, colaborar en el código, probar e implementar, todo con repositorios Git privados gratuitos. Los equipos eligen Bitbucket porque tiene una integración superior de Jira, CI / CD incorporado y es gratuito para hasta 5 usuarios. Por otro lado Jenkins se detalla como "Un servidor de integración continua de código abierto extensible". En pocas palabras, Jenkis CI es el servidor líder de integración continua de código abierto. Construido con Java, proporciona más de 300 complementos para apoyar la creación y prueba de prácticamente cualquier proyecto.

Bitbucket se puede clasificar como una herramienta en la categoría "Colaboración de código y control de versioens", mientras que Jenkins se agrupa en "Integración continua".

Algunas de las características que ofrece Bitbucket son:

1.- Repositorios privados ilimitados, cobrados por usuario

2.- La mejor integración de Jira en su clase

3.- CI / CD incorporado

Por otro lado, Jenkinks proporciona las siguintes características clave:

1.- Fácil instalación

2.- Configuración fácil

3.- Cambiar conjunto de soporte

Los "repositorios privados gratuitos", la "Configuración simple" y la "Buena interfaz de usuario y herramientas" son los factores clave por los que los desarrolladores consideran Bitbucket mientras que "Hospedado internamente", "Código abierto gratuito" y "Excelente para construir, implementar o lanzar cualquier cosa asíncrona" son las razones principales por las que Jenkis es favorecida.

Jenkins es una herramienta de código abierto con 13.2K estrellas GitHub y 5.43 horquillas GitHub. Aquí hay un enlace al repositorio de código abierto de Jenkins en GitHub.

Fuente: Texto encontrado por internet anónimo.

BUENO BUENO ESTA ES YA LA LECHE LA ACABO DE DESCUBRIR - I LOVE COUNTRY


 





ENTRADA SOBRE EXTREMING PROGRAMMING (XP)

ELEMENTOS EN EL PROCESO DE DESARROLLO DE LA METODOLOGIA XP.

Los pasos fundamentales inmersos en las fases del método son:

1.- Desarrollo iterativo e incremental: Pequeñas mejoras, unas tras otras.

2.- Pruebas unitarias continuas: Son frecuentemente repetidas y automatizadas, incluyendo pruebas de regresión. Se aconseja escribir el código de la prueba antes de la codificación.

3.- Programación en parejas: Se recomienda que las tareas de desarrollo se lleven a cabo por dos personas en un mismo puesto. Se supone que la mayor calidad del código escrito de esta manera – el código es revisado y discutido mientras se escribe – es más importante que la posible pérdida de productividad inmediata.

4.- Frecuente integración del equipo de programación con el cliente o usuario: Se recomienda que un representante del cliente trabaje junto al equipo de desarrollo. Corrección de todos los errores antes de añadir nueva funcionalidad. Hacer entregas frecuentes.

5.- Refactorización del código: Es decir, reescribir ciertas partes del código para aumentar su legibilidad y Mantenibilidad, pero sin modificar su comportamiento. Las pruebas han de garantizar que en la refactorización no se ha introducido ningún fallo.

6.- Propiedad del código compartido: En vez de dividir la responsabilidad en el desarrollo de cada módulo en grupos de trabajo distintos, este método promueve el que todo el personal pueda corregir y extender cualquier parte del proyecto. Las frecuentes pruebas de regresión garantizan que los posibles errores serán detectados.

7.- Simplicidad del código: Es la mejor manera de que las cosas funcionen. Cuando todo funcione se podrá añadir funcionalidad si es necesario. La programación extrema apuesta que es más sencillo hacer algo simple y tener un poco de trabajo extra para cambiarlo si se requiere, que realizar algo complicado y quizás nunca utilizarlo.

La simplicidad y la comunicación son extraordinariamente complementarias. Con más comunicación resulta más fácil identificar qué se debe y qué no se debe hacer. Cuanto más simple es el sistema, menos tendrá que comunicar sobre éste, lo que lleva a una comunicación más completa, especialmente si se puede reducir el equipo de programadores.

  

Contenido desarrollo de software - Arquitectura Software

ENUM en JAVA