Complejidad esencial y complejidad adicional

Cuando desarrollamos software, podemos decir que nos enfocamos principalmente en resolver problemas y al resolver dichos problemas nos podemos encontrar con dos tipos de complejidad: la complejidad esencial y la complejidad adicional.

Complejidad esencial

Se refiere a la complejidad propia de construir una característica del software

Complejidad adicional

Se refiere a la complejidad que agregamos por nuestra cuenta mientras construimos la característica del software, complicando la resolución del problema por distintos factores.

Al inicio de la construcción de un sistema, su complejidad suele ser igual a la complejidad esencial y conforme pasa el tiempo la complejidad del sistema es el resultado de la suma de la complejidad esencial y complejidad adicional.

Una buena arquitectura de software debe pretender que el peso de la complejidad adicional no se incremente en demasía.

Como ejemplos podemos pensar imaginar:

  • una aplicación que como backend tiene un solo endpoint, su complejidad adicional será menor que una que tenga un backend con muchos endpoints acoplados
  • una organización en la cual durante un sprint se desarrollen varias reuniones poco productivas le agrega complejidad adicional al desarrollo.
  • evitar implementar un correcto sistema de despliegue en un inicio por ganar tiempo agrega complejidad adicional cuando el desarrollo involucre a muchos desarrolladores desplegando código.

Como podemos observar, la complejidad adicional no solo tiene que ver con el código que escribimos, la misma incluye todo el entorno en el cual desarrollamos el software, sin embargo en cuanto a código también podemos agregar gratuitamente complejidad adicional cuando el mismo no incluye mejores prácticas, estándares de desarrollo o el uso de clean code.

 

Qué es arquitectura de software

La arquitectura de software son las reglas autoimpuestas al definir como diseñamos software.

La arquitectura de software no incluye el tratamiento de asuntos relacionados al hardware de manera directa.

Respecto al diseño, existen los enfoques de micro-diseño y macro-diseño.

Por ejemplo, el micro-diseño hace referencia al diseño que realizamos cuando probamos el código de una función en un desarrollo dirigido por pruebas y el macro-diseño va más alla de la función que estamos implementando, tiene que ver con modelamos nuestro dominio a un nivel más alto, como dividimos nuestra aplicacion por capas, servicios, etc.

 

Cambiar puerto en politicas SELinux (SELinux policy) en CentOS – RedHat 6.4 – Fedora

Para permitir utilizar el puerto 443 (HTTPs) en el servicio sshd con SELinux habilitado, nos podemos basar en la siguiente guía

 

Listado de puertos utilizados por el servicio http

semanage  port -l | grep http_port_t

 
Eliminamos del servicio http y lo agregamos al servicio ssh

semanage port -d  -t http_port_t -p tcp 443
semanage port -m -t ssh_port_t -p tcp 443

 

Habilitamos el servicio SSH para que escuche por el puerto 443

vi /etc/ssh/sshd_config

 

Agregamos el puerto en el archivo

Port 443

 

Reiniciamos los servicios

/etc/init.d/sshd restart
/etc/init.d/sshd status

 

 

Configuración de variables de entorno en Tomcat de Netbeans

Cuando utilizamos el servidor tomcat que viene junto a Netbeans, en ocasiones necesitamos agregar variables de entorno para nuestras aplicaciones java, y aunque existen diversas maneras, a continuación muestro una de ellas:

Archivo setenv.sh

Se debe crear, en el caso de no existir el siguiente archivo:

~/.netbeans/8.1/apache-tomcat-8.0.27.0_base/bin/setenv.sh

Donde ~ es la ruta del directorio home del usuario en linux

La ruta puede variar ligeramente si las versiones descargadas e instaladas son distintas.
Contenido:
En el archivo setenv.sh se puede colocar las variables necesarias.

#!/bin/sh
export NOMBRE_VARIABLE="valor

Este archivo será utilizado por el tomcat de nuestro de netbeans al iniciarlo y con ello tendremos acceso a dichas variables en nuestra aplicación java