2019 Fue un gran año para mi, hice casi todas mis metas profesionales o personales, metí muchos cambios en mi vida y aunque por N motivos no pude disfrutarlas como quisiera, allí están.

En el blog no he publicado lo suficiente, los borradores existen, solo siento que puedo mejorar la redacción y tengo pensado hacer videos en lugar de solo escribir, tratar con una forma diferente de hacer las cosas para salir de mi zona de confort en esta parte.

También intenté de dedicarle tiempo a otras cosas, comencé a ir al gimnasio, igual fui 1 semana al crossfit y al final corriendo por las noches, lo máximo que pude correr fueron 10k, creo que es importante el ejericio, me ayudo mucho a resolver problemas y suavizar otros, la excusa perfecta para hacerme con un Smart Watch.

Para no hacer mas largo el post espero que tengan un prospero año nuevo.

Don't repeat yourself

Un principio del desarrollo del software muy simple, "no repitas código".

Gracias a este principio creo que muchos desarrolladores dieron forma a las librerias, prefiriendo encapsular un comportamiento deseado en un solo lugar.

Esto hace necesario administrar las librerias de una forma eficiente y fácil de utilizar en el equipo de trabajo.

Aunque podemos expresarlo en una frase tiene una complejidad muy grande al llevarlo a la practica.

Debemos ser capaces de soportar los diferentes formatos de los componentes con los que trabajamos, en mi caso utilizo Maven, NPM/Yarn, Bower y Docker.

Al buscar una solución para estos componentes llegué a la questión de ¿que será mas facil de manejar?, ¿una plataforma por cada formato o uno que englobe a todos?.

Fue así que llegue a Nexus Repository OSS.

The free artifact repository with universal support for popular formats.

Todo en uno, gratis y con soporte para mis componentes de trabajo y algunos extras , aquí una lista de los formatos soportados:

• Bower
• Docker
• Git LFS
• Maven
• npm
• NuGet
• PyPI
• Ruby Gems
• Yum
• Apt
• Conan
• R
• CPAN
• Raw (Universal)
• P2
• Helm
• ELPA

Instalación

Como ya es costumbre usaremos Docker para su instalación, podemos encontrar la imagen oficial de Nexus en Docker Hub.

En una sola linea

curl -s https://gist.githubusercontent.com/ripper2hl/f768fa89499444be9951c4d4308d6849/raw/0a377815cae4469e39fec0d6fddadb8e2db0513f/nexus-setup.sh | bash

O ejecutamos los siguientes comandos:

mkdir nexus && cd nexus

mkdir nexus-data

sudo chown -R 200 nexus-data

docker run -d -p 8081:8081 --name nexus -v nexus-data:/nexus-data sonatype/nexus3

Y ahora solo debemos entrar a la liga http://localhost:8081

Para iniciar sesión usaremos las credenciales por defecto que son admin y admin123.

Para utilizar Nexus cada formato requiere su propia configuración de los repositorios privados, en este caso, configuraremos Maven como ejemplo.

Configuración Maven

Crearemos un archivo llamado settings.xml en el directorio .m2 que se encuentra en nuestro home como se muestra en el siguiente ejemplo.

<settings>
  <mirrors>
    <mirror>
      <id>nexus</id>
      <mirrorOf>*</mirrorOf>
      <url>http://localhost:8081/repository/maven-public/</url>
    </mirror>
  </mirrors>
  <profiles>
    <profile>
      <id>nexus</id>
      <repositories>
        <repository>
          <id>central</id>
          <url>http://central</url>
          <releases><enabled>true</enabled></releases>
          <snapshots><enabled>true</enabled></snapshots>
        </repository>
      </repositories>
     <pluginRepositories>
        <pluginRepository>
          <id>central</id>
          <url>http://central</url>
          <releases><enabled>true</enabled></releases>
          <snapshots><enabled>true</enabled></snapshots>
        </pluginRepository>
      </pluginRepositories>
    </profile>
  </profiles>
  <activeProfiles>
    <activeProfile>nexus</activeProfile>
  </activeProfiles>
  <servers>
    <server>
      <id>nexus</id>
      <username>admin</username>
      <password>admin123</password>
    </server>
  </servers>
</settings>

Probaremos que funciona con un proyecto real:

git clone https://github.com/ripper2hl/dockerejemplos.git

cd dockerejemplos/java

mvn clean install

Si todo esta bien deberíamos algo así en la terminal:

[INFO] Scanning for projects...
[INFO] 
[INFO] -----------------------< javadocker:javadocker >------------------------
[INFO] Building javadocker 1.0-SNAPSHOT
[INFO] --------------------------------[ jar ]---------------------------------
Downloading from nexus: http://localhost:8081/repository/maven-public/org/apache/maven/plugins/maven-compiler-plugin/3.1/maven-compiler-plugin-3.1.pom
Downloaded from nexus: http://localhost:8081/repository/maven-public/org/apache/maven/plugins/maven-compiler-plugin/3.1/maven-compiler-plugin-3.1.pom (0 B at 0 B/s)
Downloading from nexus: http://localhost:8081/repository/maven-public/org/apache/maven/plugins/maven-compiler-plugin/3.1/maven-compiler-plugin-3.1.jar
Downloaded from nexus: http://localhost:8081/repository/maven-public/org/apache/maven/plugins/maven-compiler-plugin/3.1/maven-compiler-plugin-3.1.jar (0 B at 0 B/s)
Downloading from nexus: http://localhost:8081/repository/maven-public/org/apache/maven/plugins/maven-assembly-plugin/2.2-beta-5/maven-assembly-plugin-2.2-beta-5.pom
Downloaded from nexus: http://localhost:8081/repository/maven-public/org/apache/maven/plugins/maven-assembly-plugin/2.2-beta-5/maven-assembly-plugin-2.2-beta-5.pom (0 B at 0 B/s)
Downloading from nexus: http://localhost:8081/repository/maven-public/org/apache/maven/plugins/maven-plugins/16/maven-plugins-16.pom
Downloaded from nexus: http://localhost:8081/repository/maven-public/org/apache/maven/plugins/maven-plugins/16/maven-plugins-16.pom (0 B at 0 B/s)
Downloading from nexus: http://localhost:8081/repository/maven-public/org/apache/maven/plugins/maven-assembly-plugin/2.2-beta-5/maven-assembly-plugin-2.2-beta-5.jar
.
.
.

En Nexus vemos que se crea un cache de los paquetes que descargamos y así también ayudamos a ahorrar ancho de banda.

Este ejemplo es especificamente del formato de maven, para configurar otros formatos, podemos seguir la guiá del blog oficial.

https://blog.sonatype.com/using-nexus-3-as-your-repository-part-1-maven-artifacts

Mantener el orden y tener nuestros componentes a la mano, nos dará el impulso de llevar el flujo de trabajo a otro nivel.

Tal vez existan mejores alternativas a Nexus pero me ha funcionado y aun no busco un reemplazo a esta herramienta.

Después de escuchar mucho sobre la agilidad y medir la calidad del código en muchos blogs, comencé a preguntar a amigos como revisaban sus proyectos.

La mayoría no lo hacían por que en sus empresas tienen un departamento de 'QA', a lo que yo les recomendé usar FindBugs , un plugin sencillo para Eclipse que conocí allí por el 2014 y que me salvo de muchas.

Al instalarlo y correrlo por primera vez me di cuenta de la falta que me hacia, ¿solo se media la calidad por los bugs?, ¿no había otra cosa que medir? , cuanto mas ví el termino deuda técnica en los blogs, sentí que algo estaba mal en mi código.

Creo que fue en este post donde encontré algo llamado Sonar.

Su nombre completo es Sonarqube, es un Software Open Source que te ayuda a medir la calidad del código, donde combina FindBugs con otros proyectos para medir prácticamente TODO y te lo da en una amigable interfaz web a modo de reportes.

¿Como se instala?

Al ser una aplicación cliente/servidor se necesita una base de datos SQL Server / Oracle / PostgreSQL y debemos blablabla ...
Puff! las instalaciones son tediosas, puedes irte a la antigua instalando base de datos desde 0 , pero en estos años, ¿quien no tiene Docker instalado en su maquina ?.

Instala Docker y docker-compose

Una vez hecho esto, debemos crear un directorio llamado Sonarqube y el archivo docker-compose.yml

version: "2"

services:

  sonarqube:
    image: sonarqube:latest
    ports:
      - "9000:9000"
    networks:
      - sonarnett
    environment:
      - SONARQUBE_JDBC_URL=jdbc:postgresql://db:5432/sonar
    volumes:
      - sonarqube_conf:/opt/sonarqube/conf
      - sonarqube_data:/opt/sonarqube/data
      - sonarqube_extensions:/opt/sonarqube/extensions
      - sonarqube_bundled-plugins:/opt/sonarqube/lib/bundled-plugins

  db:
    image: postgres:9.6
    mem_limit: 256m
    networks:
      - sonarnett
    environment:
      - POSTGRES_USER=sonar
      - POSTGRES_PASSWORD=sonar
    volumes:
      - postgresql:/var/lib/postgresql
      - postgresql_data:/var/lib/postgresql/data

networks:
  sonarnett:
    driver: bridge
  default:
    driver: bridge

volumes:
  sonarqube_conf:
  sonarqube_data:
  sonarqube_extensions:
  sonarqube_bundled-plugins:
  postgresql:
  postgresql_data:

Así se ve la salida de tree:

perales@linux-h4ne:~/Escritorio> tree sonarqube/
sonarqube/
└── docker-compose.yml

0 directories, 1 file
perales@linux-h4ne:~/Escritorio> 

Y ejecutamos docker-compose up

Veremos algo así:

Creating network "sonarqube_sonarnett" with driver "bridge"
Creating volume "sonarqube_sonarqube_conf" with default driver
Creating volume "sonarqube_sonarqube_data" with default driver
Creating volume "sonarqube_sonarqube_extensions" with default driver
Creating volume "sonarqube_sonarqube_bundled-plugins" with default driver
Creating volume "sonarqube_postgresql" with default driver
Creating volume "sonarqube_postgresql_data" with default driver
Pulling sonarqube (sonarqube:latest)...
latest: Pulling from library/sonarqube
e79bb959ec00: Pull complete
d4b7902036fe: Pull complete
1b2a72d4e030: Pull complete
d54db43011fd: Pull complete
1a97c78dad71: Pull complete
6dcb79eeeda4: Pull complete
bd56246cf4fd: Pull complete
88cea60f56c5: Pull complete
7ed4501359c8: Pull complete
4bbf191118e2: Pull complete
11032ed7b930: Pull complete
c59744850b29: Pull complete
Digest: sha256:7e3086215d86430bb1bde555d755605e351f59ed7fa721aaff0d7478b665086a
Status: Downloaded newer image for sonarqube:latest
Pulling db (postgres:9.6)...
9.6: Pulling from library/postgres
27833a3ba0a5: Already exists
ed00742830a6: Already exists
dc611c2aceba: Already exists
a61becab5279: Already exists
8dcff41e7aea: Already exists
820bf1bbf0d7: Already exists
050804429905: Already exists
782c81275334: Already exists
89de6f9e489b: Pull complete
6fd7948190c1: Pull complete
2b248dfe0f9f: Pull complete
2bb82f5734a9: Pull complete
6165fd6c366d: Pull complete
b91f3b4e0a77: Pull complete
Digest: sha256:ee723e25ac72edaede1c7209c33f295b56875bdee62fa08f913117c2fbca9287
Status: Downloaded newer image for postgres:9.6
Creating sonarqube_db_1        ... done
Creating sonarqube_sonarqube_1 ... done
Attaching to sonarqube_db_1, sonarqube_sonarqube_1

Al terminar el log de la consola entramos a la liga http://localhost:9000 y podremos ver la interfaz web.

Para loguearnos usamos admin, admin.

¿Como se usa?

Sonar esta vació, ¿como lo usamos?, la dinámica a seguir es la siguiente:

• Tenemos un código fuente.

• Agregamos un archivo de configuración de sonar(sonar-project.properties).

• Generamos un token de autentificación y lo agregamos a la configuración.

• Ejecutamos el analizador de código de nuestra preferencia.

Analicemos un proyecto de ejemplo:

Clonamos el repo

git clone https://github.com/ripper2hl/fuego.git

Agregamos el archivo sonar-project.properties

cd fuego/

touch sonar-project.properties

Aquí la documentación de como configurar lo

https://docs.sonarqube.org/display/SCAN/Analyzing+with+SonarQube+Scanner

Así debería de quedarnos:

sonar.projectName=fuego
sonar.projectKey=com.perales:fuego
sonar.host.url=http://localhost:9000
sonar.sources=src/
sonar.sourceEncoding=UTF-8

Para generar el token debemos ir a My Account que se encuentra en la parte superior derecha y después a la pestaña de Security, esta es la liga http://localhost:9000/account/security/ .

El token se agrega al archivo de propiedades como sonar.login

sonar.projectName=fuego
sonar.projectKey=com.perales:fuego
sonar.host.url=http://localhost:9000
sonar.sources=src/
sonar.sourceEncoding=UTF-8
sonar.login=1d5a5466cec2a33ead727a2082454e25b9cdef49

Ahora debemos ejecutar un Sonar Scanner , de los cuales existen diferentes tipos, para java existe uno que se combina con maven , pero nosotros usaremos un binario de propósito general, el cual funciona para cualquier lenguaje de programación.

En esta liga puedes descargar los binarios, GNU/Linux, Mac OS o Windows

https://docs.sonarqube.org/display/SCAN/Analyzing+with+SonarQube+Scanner

En GNU/Linux creamos un enlace simbólico para poder ejecutarlo desde terminal

ln -s ~/Descargas/sonar-scanner-3.3.0.1492-linux/bin/sonar-scanner ~/.local/bin/sonar-scanner

Si ejecutamos sonar-scanner --version nos debe mostrar esto:

sonar-scanner --version
INFO: Scanner configuration file: /home/perales/Descargas/sonar-scanner-3.3.0.1492-linux/conf/sonar-scanner.properties
INFO: Project root configuration file: NONE
INFO: SonarQube Scanner 3.3.0.1492
INFO: Java 1.8.0_121 Oracle Corporation (64-bit)
INFO: Linux 5.0.11-1-default amd64

Para analizar nuestro proyecto , solamente ejecutamos sonar-scanner en la raíz del proyecto y la terminal mostrara lo siguiente:

INFO: Scanner configuration file: /home/perales/Descargas/sonar-scanner-3.3.0.1492-linux/conf/sonar-scanner.properties
INFO: Project root configuration file: /home/perales/Documentos/git/fuego/sonar-project.properties
INFO: SonarQube Scanner 3.3.0.1492
INFO: Java 1.8.0_121 Oracle Corporation (64-bit)
INFO: Linux 5.0.11-1-default amd64
INFO: User cache: /home/perales/.sonar/cache
INFO: SonarQube server 7.7.0
INFO: Default locale: "es_MX", source code encoding: "UTF-8"
INFO: Load global settings
INFO: Load global settings (done) | time=275ms
INFO: Server id: 243B8A4D-AWqQ27WJuNHxbkg6tnXs
INFO: User cache: /home/perales/.sonar/cache
INFO: Load/download plugins
INFO: Load plugins index
INFO: Load plugins index (done) | time=125ms
INFO: Load/download plugins (done) | time=4077ms
INFO: Process project properties
INFO: Execute project builders
INFO: Execute project builders (done) | time=34ms
INFO: Project key: com.perales:fuego
INFO: Base dir: /home/perales/Documentos/git/fuego
INFO: Working dir: /home/perales/Documentos/git/fuego/.scannerwork
INFO: Load project settings for component key: 'com.perales:fuego'
INFO: Load project repositories
INFO: Load project repositories (done) | time=32ms
INFO: Load quality profiles
INFO: Load quality profiles (done) | time=305ms
INFO: Load active rules
INFO: Load active rules (done) | time=6580ms
INFO: Indexing files...
INFO: Project configuration:
INFO: 6 files indexed
INFO: 0 files ignored because of scm ignore settings
INFO: Quality profile for js: Sonar way
INFO: Quality profile for web: Sonar way
INFO: ------------- Run sensors on module fuego
INFO: Load metrics repository
INFO: Load metrics repository (done) | time=200ms
INFO: Sensor JaCoCo XML Report Importer [jacoco]
INFO: Sensor JaCoCo XML Report Importer [jacoco] (done) | time=11ms
INFO: Sensor SonarJS [javascript]
INFO: 3 source files to be analyzed
INFO: 3/3 source files have been analyzed
INFO: Sensor SonarJS [javascript] (done) | time=2646ms
INFO: Sensor ESLint-based SonarJS [javascript]
INFO: 3 source files to be analyzed
INFO: Sensor ESLint-based SonarJS [javascript] (done) | time=9792ms
INFO: Sensor JavaXmlSensor [java]
INFO: 3/3 source files have been analyzed
INFO: Sensor JavaXmlSensor [java] (done) | time=20ms
INFO: Sensor HTML [web]
INFO: Sensor HTML [web] (done) | time=395ms
INFO: ------------- Run sensors on project
INFO: Sensor Zero Coverage Sensor
INFO: Sensor Zero Coverage Sensor (done) | time=115ms
INFO: SCM provider for this project is: git
INFO: 4 files to be analyzed
INFO: 4/4 files analyzed
INFO: Calculating CPD for 4 files
INFO: CPD calculation finished
INFO: Analysis report generated in 451ms, dir size=91 KB
INFO: Analysis report compressed in 165ms, zip size=21 KB
INFO: Analysis report uploaded in 1700ms
INFO: ANALYSIS SUCCESSFUL, you can browse http://localhost:9000/dashboard?id=com.perales%3Afuego
INFO: Note that you will be able to access the updated dashboard once the server has processed the submitted analysis report
INFO: More about the report processing at http://localhost:9000/api/ce/task?id=AWqie1fuYKZYNF3HzZ-O
INFO: Analysis total time: 36.800 s
INFO: ------------------------------------------------------------------------
INFO: EXECUTION SUCCESS
INFO: ------------------------------------------------------------------------
INFO: Total time: 44.311s
INFO: Final Memory: 18M/291M
INFO: ------------------------------------------------------------------------

Si vamos a la interfaz web, podremos ver los reportes generados.

Fuentes:

• https://www.sonarqube.org/

Actualmente me encuentro trabajando bajo mucha presión y por esta razón necesito que los recursos de mi PC estén 100% enfocados en el desarrollo.

Tener arriba los servicios de Docker, IntelliJ y Firefox hacen que GNOME Shell se sienta pesado, cuando instale Open SUSE Tumbleweed me dí cuenta que tenia otros escritorios además de GNOME con Wayland y GNOME con Xorg, uno de ellos es ICEWM.

ICEWM es un entorno de escritorio a la Windows, muy ligero y me permite trabajar con fluidez, tiene los 4 escritorios acomodados de forma horizontal, un botón de inicio, una barra de tareas no personalizable y un monitor de recursos sencillo aun lado del reloj, lo único que necesito.

Este minimalismo, como siempre llega a ser un problema, ya que ahora faltan opciones que en GNOME son fundamentales, como lo es la selección de redes WIFI o cableadas, para la cual uno debe correr el siguiente comando por terminal.

nm-applet &

Listo aparecerá un icono para seleccionar la red que necesites.

Después puede que se cambie el teclado y por mas que busques no encontraras nada en el menú para poder cambiar la distribución del teclado.

Para cambiar la distribución a español, debes ejecutar el siguiente comando.

setxkbmap -option grp:switch,grp:alt_shift_toggle,grp_led:­scroll es

Listo teclado en Español.

Si queremos cuidar nuestra vista con el filtro de luz azul corremos el comando :

redshift -O 3200k

Existen algunas otras cosas molestas de este muy ligero entorno de escritorio, como que al presionar ctrl + alt + t en lugar de abrir Gnome Terminal , termina abriendo xterm, no se puede personalizar el toolbar de inicio y pequeños detalles que al inicio te hacen extrañar GNOME, pero que conforme estas trabajando, ya ni te importan, el rendimiento lo compensa.

Fuentes

• https://ice-wm.org/

El nombre completo del curso se llama Agilidad y Lean. Gestionando los proyectos y negocios del siglo. XXI (7ª. edición) , este curso esta alojado en la plataforma Miriada X, en la cual ya había hecho anteriormente un curso de aplicaciones web para Firefox OS.

No se si la persona que lo creo tenga en cuenta que México es el país que mas horas trabaja de la OCDE o que sólo el 1.7% de las personas gana más de 20 mil pesos al mes(unos 875 Euros).

Lo anterior va por que a lo largo del curso se estudia los principios del manifiesto ágil, uno de ellos es Individuos e Interacciones sobre procesos y herramientas y vemos temas como el people ware, no trabajar mas de 40 horas por semana, niko niko para 'medir' la felicidad de los equipos, Kudo box para incentivar la motivación, auto organización, equipos pequeños, transferencia del conocimiento por medio de la programación en pareja y lo que le sigue a la programación en pareja llamado Mob Programming.

Se comienza con una animación sin sonido de un equipo de 3-4 personas que están por utilizar SCRUM para desarrollar un proyecto.

En la primera lección se hace referencia que debemos estar conscientes de que hacer software no es lo mismo que construir casas o carros, por que nuestro trabajo la mayoría de las veces es intangible, lleva un proceso de construcción intelectual, es una industria relativamente joven, el software es difícil de predecir, la agilidad no es para todos los proyectos, aunque debería estar presente en mas de los que esta hoy y se debe evitar tener un rambo(persona que es la única que puede modificar ese Stored Procedure de 20k de lineas) en el equipo.

En las lecciones 3( El “Product Owner” y las historias de usuario
), 4(SCRUM) y 5(La planificación ágil) se tratan temas muy ligados a SCRUM y a lo que se le podría llamar agilidad "clásica" , te enseña lo que es, las practicas y técnicas para estimar(Planning poker), organizar (Board, historias de usuario, juntas) y como medir el rendimiento de un proyecto(Burn down y Burn up), velocidad, así como algunos consejos y comparaciones con el ciclo de vida en cascada(historias de usuario vs casos de uso).

Después en las ultimas lecciones 6(Lean y Kanban) y 7(Deuda Técnica y Testing Ágil), hablan de cosas que vi en la facultad como Lean y sabia que de alguna forma se podía aplicar al desarrollo de software, pero nunca lo concretaron en ninguna clase, era mas para manufactura de piezas o productos de acero, cosas que realmente no me importan.

Entonces saltan nombres en el curso como Toyota y Deming hablando sobre el éxito de la calidad, los principios de la calidad y como se aplica al proceso de creación del software como un producto, eliminar el desperdicio, re aprendizaje, etc.

Aparece un concepto nuevo para mi llamado Kanban, que es la técnica principal de Lean, la traducción de Google es letrero, en el curso se maneja como tarjeta visual y trata de tener la visibilidad del trabajo, limitarlo y controlar el flujo del mismo.

Para la visibilidad del trabajo se habla de los elementos/ítems que tenemos como tareas, ya sea una historia de usuario, un issue, requisito, funcionalidad nueva, etc. Debemos definir les los estados en los que pueden estar y que significado tiene cada uno, ya que muchas veces lo que una persona del equipo entiende por terminado no es lo que otros piensan.

Por ejemplo yo puedo decir que ya esta reparado un error y hasta lo tengo en la rama de desarrollo, pero quizá si mi jefe me pregunta, el esperaría que ese reparado es por que ya esta en producción, con esto tratamos de evitar los malos entendidos.

También vuelve la importancia de los tableros en físico en el lugar de trabajo para que sea visible para todo el equipo y que tu tablero de SCRUM se vuelve casi lo mismo que un tablero de Kanban, la diferencia es que Kanban no limita por tiempo, cosa que SCRUM si, con los sprints.

En la limitación del trabajo trata el concepto WIP(Work In Progress, presente en Gitlab ), en el que no debemos de tener mas de "n" cosas sin terminar al mismo tiempo, se debe definir cuantas tareas pueden estar abiertas en cada uno de los estatus y respetarlo, para centrar el equipo en cerrar tareas, por eso de muchas tareas abiertas y ninguna terminada.

La última lección es más técnica y me da entender que no importa que metodología uses, ya sea tradicional o ágil, la excelencia tecnología es lo más importante.

Esto es así por qué si no controlas y mides la complejidad del código en tus proyectos, estos terminan arrastrándose como un zombi, en el que día a día se le van agregando pedazos y pedazos de parches y lo que antes te tomaba un día hacerlo, ahora te toma 2 semanas, ¿Les ha pasado?.

Aquí a los hacks, work arounds, métodos llenos de complejidad se les pone nombre y apellido, uno es el concepto de deuda técnica y el otro es el de la complejidad ciclomatica de los métodos o funciones.

La deuda técnica son nuestros pequeños pecados, que vamos dejando en el código para poder salir a producción, seguir operando, cosas que técnicamente están mal pero que por el contexto son necesarias.

Se explica similar a un crédito bancario donde adquieres deuda para poder ganar un beneficio a corto plazo, pero en algún momento tendrás que pagar sus intereses.

La complejidad ciclomatica en palabras simples es cuántos caminos diferentes pueden existir en tu código, estos caminos se crean por sentencias condicionantes o bucles.

Explicado lo anterior ¿por qué es tan importante mantener una complejidad ciclomatica baja?, La respuesta es que código simple es código sencillo de mantener y fácil de probar, debido a que también se aborda el tema de TDD(Test drive development), el cual evoluciona a BDD(Behavior Drive development).

El desarrollo dirigido por pruebas es una práctica que consiste en desarrollar las pruebas primero y después la implementación, seguido de un nuevo concepto llamado refactorización del código, en el que se pule el código, estás pruebas deben estar automatizadas y deben ejecutarse por lo menos diariamente al construir el ejecutable, aquí entra otro concepto técnico llamado integración continua.

La integración continua es una práctica de la cultura DevOps en la que se debe integrar el trabajo de todos los desarrolladores diariamente.

Veo que es un curso muy completo y vale mucho la pena si estas envuelto en esto del software, aunque no seas desarrollador, muchas técnicas e ideas de este curso te vendrán a la mente en el día a día de tu trabajo en los problemas de organización, normalmente los proyectos de software fracasan por mala organización, ademas se ve muy padre el certificado en Linkedin.

Fuentes:

• http://www.javiergarzas.com/

• https://miriadax.net/web/agilidad-lean-gestionando-proyectos-negocios-sxxi

Siempre que trabajamos con el bash nunca esta de mas una ayuda, en este caso el completado de los comandos nos sera útil, después de escribir docker im presionamos tab y nos sales algunas opciones.

Como súper usuario ejecutamos el siguiente comando, salimos y volvemos a entrar a la consola.

curl https://raw.githubusercontent.com/docker/docker-ce/master/components/cli/contrib/completion/bash/docker -o /etc/bash_completion.d/docker.sh

Para instalar en nano es necesario tener la contraseña del usuario root y ejecutar los siguientes comandos

Si estas en SLES 12 SP 3

zypper addrepo https://download.opensuse.org/repositories/editors/SLE_12_SP3/editors.repo

zypper refresh

zypper install nano

Si estas en SLES 15

zypper addrepo https://download.opensuse.org/repositories/editors/SLE_15/editors.repo

zypper refresh

zypper install nano

Aunque siempre debemos conocer un poco como funciona vi, no sabemos cuando nos puede ser útil.

Al grano:

Se escribe en la barra navegación about:config , aceptamos el riesgo y después buscamos devtools.debugger.new-debugger-frontend , damos click derecho y cambiamos de true a false, ya podrias depurar javascript de nuevo.

Esto parece suceder debido a que se esta cambiando el depurador por uno nuevo y en Firefox edición para desarrolladores esta activado por defecto, por lo cual debemos desactivarlo y tendremos el viejo y confiable depurador, solo hasta que se encuentre mas estable, en teoría traerá muchas mejoras.

Fuentes

• https://developer.mozilla.org/en-US/docs/Tools/Debugger/Limitations_of_the_new_debugger

Aunque la distribución que mas me gusta es Fedora, por que era la primera en adoptar las actualizaciones de GNOME , es patrocinada por Redhat y un largo etcétera, normalmente compartía mi Laptop con mas personas de mi familia y para ellos era mas sencillo usar Ubuntu, no iba a instalar Windows, así que por un largo tiempo utilice esa distribución.

Desde siempre me sentí cómodo con GNOME, mi primer contacto con GNU/Linux fue con Backtrack 3, utilizaba GNOME 2.

Cuando vi que no era recomendado usar Backtrack para uso diario las primeras distribuciones en aparecer fueron Ubuntu , Fedora y OpenSUSE, probé las 3 y solo una de esas usaba KDE, no me acostumbre y la abandone.

Ubuntu es muy fácil de instalar, usar, y actualizar, tanto en sus versiones de escritorio como en sus versiones de servidor, no puedo criticarle rendimiento y también las aplicaciones populares siempre hacen primero un DEB que un RPM.

Unity, el shell por defecto de Ubuntu, por que seguía siendo GNOME, es bonito y poderoso, tiene muy bueno atajos del teclado y al dejar presionado el botón de Super/Windows aparecía la lista completa.

Lo único malo es que Unity como muchos otros proyectos fueron descontinuados por Canonical, la empresa que pone los billetes para que todo ocurra y Ubuntu regreso a GNOME Shell, que en lo personal también me gusta, pero le harán unos cuantos retoques, si bien eso no me hizo cambiar de distribución es algo que calo mucho en la comunidad.

Soy una persona que sufre de versionitis, siempre antes de empezar a trabajar, actualizo todas mis herramientas, comienzo por correr un sudo apt-get update && sudo apt-get upgrade -y y listo.

Pero después me doy cuenta que en los repositorios de Ubuntu la mayoría solo actualiza para correcciones y comienzo a agregar los PPA de los portales de las aplicaciones.

Un ejemplo es Docker que ahora lanzara versiones nuevas de forma frecuente y el repositorio oficial de Ubuntu se quedará desfasado, espero que no.

La otra es que es una distribución Standar Release, que cada vez que sale una nueva versión de Ubuntu es necesario correr el proceso de actualización, si bien es estable no le quita lo tedioso, cosa que nunca pasará con una distribución Rolling Release, en teoría.

Y con Rolling Release comienza a sonarme ArchLinux y Manjaro , distros que nunca use, pero que me agradaba la idea.

Desde el 2014 comencé a escuchar que OpenSUSE fusionaría sus proyectos Rolling Release (Factory y Tumbleweed), desde allí seguí un poco el proyecto.

Por temas de seguridad quería cifrar mi disco duro, pero solo es posible hacerlo al momento de instalar el sistema operativo, después solo es posible cifrar la carpeta del usuario, tenía que reinstalar Ubuntu o quizá instalar otra distribución.

Después de dejar de compartir mi Laptop, era tiempo de un cambio y me decidí por dejar Ubuntu y usar Tumbleweed con GNOME.

Aunque el proceso de instalación no fue sencillo, la verdad es que les hace mucha falta pulir, no me di por vencido y logre instalar Tumbleweed, con mi disco duro cifrado y la ultima versión de GNOME.

Para estar siempre a la ultima en actualizaciones es necesario correr los comandos

sudo zypper up
sudo zypper dup

Mi primera impresión es que es un sistema estable, solo le hacia falta algo de color, instale un tema de iconos y cambie las fuentes por una MONO, todo funciona como debe ser, eso si, por el cifrado tarda un poco en iniciar el SO, pero la seguridad lo vale.

Comenzare a escribir un poco mas sobre como me va con Tumbleweed en este año, que por las prisas no he dedicado ni un post para despedir el 2017, el cual mi blog se vio algo abandonado.

Conclusión

OpenSUSE Tubleweed es una distribución excelente para quien sufre de versionitis.

Solo puedo decir que estoy contento y desde hace mas de 8 meses no tengo ningún problema con mi computadora.

Todos los paquetes siempre a la ultima, el kernel, GNOME, los controladores gráficos, etc, un sueño, para quien siempre quiere las ultimas versiones, que creo que es el publico para el que esta pensado este tipo de distribuciones.

La instalación es sencilla si usas la configuración por defecto, pero si quieres cifrar tu disco, cambiar de EXT4 a BRTFS , tendrás problemas, aunque quizá eso ya este solucionado.

No le pide nada a Ubuntu y como ya todo es/sera GNOME Shell, no notaras tanto el cambio, hoy ya me encuentro corriendo GNOME 3.28.0.

Normalmente Docker utiliza una serie de configuraciones internas de red, entre ellas crea una interfaz de red llamada docker0 la cual nunca nos molestara, a menos que utilices direcciones IP que comiencen con 172.x.x.x, es entonces cuando debemos crear/modificar el archivo daemon.json y agregar un segmento de red que no nos moleste.

{
  "bip": "192.168.200.0/16"
}

El archivo daemon.json normalmente se debe crear/encontrar en la ruta /etc/docker/daemon.json de nuestro SO.

Si usas windows lo puedes encontrar en C:\ProgramData\Docker\config\daemon.json.

Actualización

Con la solución anterior solo funcionaba para los contenedores
creados de la forma clásica, pero si utilizamos docker swarm o docker compose, esa configuración se ayudaba, aquí la solución definitiva.

{
  "default-address-pools" : [
    {
      "base" : "192.168.200.0/16",
      "size" : 24
    }
  ]
}

Pueden seguir el hilo de este problema en Github

Hace tiempo trabaje con una maquina la cual tenia instalado Fedora 20 (Heisenbug), aun recuerdo que eran los días de las peleas por Systemd y que ya comenzabas usar DNF en lugar de YUM.

A la fecha de hoy Seth Vidal, el creador de YUM, esta muerto, muchas gracias por esta pieza clave en una de mis distribuciones favoritas de GNU/Linux.

Por cosas del destino hoy me toca darle una actualización a esta maquina, en mi trabajo actual tengo una con capacidades similares, pero utiliza Windows y puedo ver como el rendimiento en GNU/Linux es muy superior, esta cosa vuela.

Primero que nada siempre hago mi respaldo con Deja dup, aunque sea en el mismo disco duro, los datos se mantienen a salvo, si algo pasa una distro Live puede entrar al rescate.

Un problema que se me presento es que tenia la partición root llena por una base de datos de MySQL, hice un respaldo y borre las bases de datos, pero el espacio en el disco duro no regreso :( .

La solución fue básicamente, parar el servidor de Mysql y borrar algunos ficheros.

 sudo systemctl stop mysql
 sudo rm /var/lib/mysql/ibdata1 
 sudo rm /var/lib/mysql/ib_logfile
 sudo rm /var/lib/mysql/ib_logfile0 
 sudo rm /var/lib/mysql/ib_logfile1 
 sudo systemctl start mysql

https://stackoverflow.com/questions/3456159/how-to-shrink-purge-ibdata1-file-in-mysql/3456885#3456885

¡Espacio en el disco recuperado!

El segundo problema es que para hacer una actualización de Fedora siempre se tiene que revisar que todos los paquetes estén actualizados, cosa que no podía realizar ya que me pedía actualizar MySQL por MariaDB y yo no quería hacerlo.

Intente bloquear el paquete con package lock pero no me funciono , me lo seguía marcando y no me dejaba avanzar, afortunadamente la solución esta en la guiá de actualización de Mysql a mariadb.

Entras como súper usuario y excluyes todos los paquetes de mariadb de las actualizaciones con el siguiente comando.

echo "exclude=mariadb*" >> /etc/yum.conf

https://fedoraproject.org/wiki/Features/ReplaceMySQLwithMariaDB

El tercer problema es que no es posible actualizar Fedora a su ultima versión, así como así, se debe pasar por Fedora 20 --> 21 --> 22 --> 23 --> 24 --> 25 --> 26 , gracias a Redhat por mantener los repositorios vivos de Fedora 20 y compañía.

Manos a la obra

La guiá de instalación de fedora nos dice que se tiene que tener todo actualizado, ya cumplido, hacer un backup, también ya cumplido y ahora solo toca correr los comandos para instalar Fedup, creo que ya cambio de nombre.

sudo yum install fedup 

Rezamos a java.lang.Object y ejecutamos

sudo fedup --network 21 --product=workstation

Ya solo queda reiniciar y esperar

Una ultima advertencia de MySQL y antes de irnos una captura de pantalla de Firefox 38.

Después de reiniciar en el grub apareció una opción con el nombre de Fedup, al seleccionarla se comienza la actualización del sistema.

Todo parecía bien pero al momento de iniciar sesión solo se quedo allí y tuve que entrar por las terminales CTRL + ALT F2 y me di cuenta que algunos paquetes no se habían actualizado por la culpa de MySQL, así que lo tuve que des-instalar y despues dar un yum update seguido de un yum dist-synch

Y listo ya estamos en Fedora 21

Sigue el 22

Nos apoyaremos en la guiá de actualización.

https://fedoramagazine.org/upgrade-fedora-21-fedora-22/

Nos dice es que el primer comando a ejecutar es

sudo dnf update

Y aquí otro problema

Traceback (most recent call last):
  File "/bin/dnf", line 36, in <module>
    main.user_main(sys.argv[1:], exit_code=True)
  File "/usr/lib/python2.7/site-packages/dnf/cli/main.py", line 185, in user_main
    errcode = main(args)
  File "/usr/lib/python2.7/site-packages/dnf/cli/main.py", line 84, in main
    return _main(base, args)
  File "/usr/lib/python2.7/site-packages/dnf/cli/main.py", line 115, in _main
    cli.configure(map(ucd, args))
  File "/usr/lib/python2.7/site-packages/dnf/cli/cli.py", line 981, in configure
    self.optparser.usage = self.optparser.get_usage()
  File "/usr/lib/python2.7/site-packages/dnf/cli/option_parser.py", line 255, in get_usage
    usage += "%-25s %s\n" % (name, summary)
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 40: ordinal not in range(128)

Parece que algo no le gusta y la solución que nos dan es cambiar el nombre a un archivo que se encuentra en la ruta /usr/share/locale/es/LC_MESSAGES/dnf-plugin-system-upgrade.mo, así que solo hay que renombrarlo

sudo mv /usr/share/locale/es/LC_MESSAGES/dnf-plugin-system-upgrade.mo /usr/share/locale/es/LC_MESSAGES/dnf-plugin-system-upgrade.mo.backup

Aquí la fuente

https://ask.fedoraproject.org/es/question/75573/como-solucionar-este-error-solucionado/

Después de tener esto solucionado ahora toca de nuevo instalar Fedup

sudo dnf install fedup

Y de nuevo otro error que se soluciona, des-instalando y reinstalando Fedup

sudo dnf remove fedup
sudo dnf install fedup

Ejecutamos el comando definitivo para la actualización.

sudo fedup --network 22

Ahora solo tengo que reiniciar.

Actualizar a Fedora 23

Ya vamos casi a la mitad del camino, ahora sigue la guiá del 22 al 23.

https://fedoramagazine.org/upgrading-from-fedora-22-to-fedora-23/

Se debe actualizar los paquetes con el siguiente comando, parece que tenemos variación en DNF.

sudo dnf upgrade

También podemos observar que Fedup como tal ya no se recomienda por el siguiente comando

sudo dnf install dnf-plugin-system-upgrade

sudo dnf system-upgrade download --releasever=23

sudo dnf system-upgrade reboot

Mientras corre el primer comando puedo curiosear un poco y darme cuenta del gran salto de versiones de Firefox

Al reiniciar tenemos un Fedora 23 sin problemas, ni sorpresas, todo bien, aunque creo que el proceso de actualización fue un poco mas tardado.

Vamos por la 24

Como siempre tenemos nuestra confiable guiá de Fedora Magazine

https://fedoramagazine.org/upgrading-fedora-23-workstation-to-fedora-24/

En el comando que ejecutamos encontramos mas sorpresas, ya no tenemos un update , ahora es un upgrade acompañado por un novedoso Flag.

sudo dnf upgrade --refresh

sudo dnf install dnf-plugin-system-upgrade

sudo dnf system-upgrade download --releasever=24

Solo el ultimo comando era necesario.

Después del reinicio y de dejar que pasara un tiempo para que se completara la actualización, todo quedo como debería ser y ahora tenemos un Fedora 24 sin ningún problema.

Parece ser que los desarrolladores de esta distribución se han lucido en estos últimos lanzamientos.

Vamos por el 25, ¿ mejor por el 26 ?

Igual que anteriores versiones de Fedora, buscamos la guiá de actualización la cual tiene fecha del 22 de noviembre del 2016 y nos tiene una bonita sorpresa, la recomendación ahora es utiliza Gnome Software.

Adiós a la terminal, aunque tenemos esa opción si queremos, pero hagamos caso a la recomendación.

Al abrir Software debemos dar clic a actualizaciones y esperar a que cargue este apartado, tengamos paciencia.

Después de un momento nos muestra lo siguiente, no se que pensar, ¿Fedora 24 a Fedora 26?.

Leer este hilo me calmo un poco y parece ser que es posible, asi que vamos a por Gnome 3.24.

https://forums.fedoraforum.org/showthread.php?t=314992

Después de un rato, parece que sigue el punto decisivo.

Nos pide reiniciar y solo es necesario armarnos de paciencia y listo.

Fedora 26 desde la versión 24.

Conclusión

Hemos visto como pasar desde fedora 20 a Fedora 26, solo las primeras 2 actualizaciones nos causaron algunos problemas, pero nada que no se pudiera resolver con algo de Google.

Las guías de fedora magazine son excelentes y se puede ver como la gente de Gnome, paso de actualizaciones con base a comandos de terminal hasta una interfaz de usuario que a punta de unos cuantos clics es posible actualizar desde Fedora 24 a 26, sin pasar por 25, un muy gran detalle, no por nada es mi distribución favorita, quizá ahora Fedora con esta madurez pase o tenga una versión Rolling Release, como en la que me encuentro ahora.

Listo para trabajar con Gnome 3.24

La funcionalidad de Luz nocturna es algo que me gusta mucho y que mis ojos agradecen, aunque se puede lograr con F.lux o con Redshift(este mas antiguo) es un gran punto tenerlo Out of the box, no se si KDE lo tenga también, pero es una idea que pueden copiar.

Comunmente cuando me encuentro trabajando puedo distraerme con facilidad, despues de investigrar un poco, encontre algunas cosas que me fuerón de utilidad,una es la tecnica pomodoro.

Utilizar la técnica pomodoro pude maximizar mis tareas en menos tiempo y aumentar mi productividad, el podmodoro funcionaba pero, sabia que podría hacerlo mejor si conseguía bajar el numero de interrupciones.

Así fue como encontré el ruido blanco que se describe como una señal de sonido que contiene todas las frecuencias y estas son de la misma potencia y se dice podría tener los siguientes beneficios:

• Aumenta el enfoque mientras mejora la privacidad
• Ayuda a dormir bloqueando las distracciones
• Relaja a los bebés.
• Relaja y reduce el estrés.
• Calma los dolores de cabeza y las migrañas
• Máscaras de tinnitus (zumbido de las orejas)

Compre unos audífonos y continuamente abría una pagina para escuchar ruido blanco, quizá me quede sordo algún día.

Note mucho la diferencia, ya no me resultaba difícil concentrarme, adiós a las interrupciones.

En el trabajo que estoy actualmente mueven las reglas de la red por lo que la pagina que accedía ayer, hoy podría estar bloqueada, por lo tanto me di a la tarea de crear una extensión en javascript para Firefox (Whitenoisefy), utilizando el API de sonido para crear ruido blanco.

Afortunadamente para mi, alguien ya había pensado en esto y creo ruido blanco, rosa y café, solo tenia que aprender a empaquetar Web Extensions.

Para este pequeño proyecto, no utilice jQuery, ni Angular, solo vanilla javascript( ¡vanilla rocks! ).

Por otro lado, aproveche para probar Bootstrap 4 , las cards, los nuevos botones outline se ven muy bien, el sistema de rejillas es mas poderoso, me sorprendió la evolución de este framework, aun recuerdo su versión 2 compitiendo con Pure de Yahoo.

Como no soy muy bueno creando logos tome alguno free de internet , los combine con Gimp, creo que se ve muy mal y debería mejorarlo, para que estén acorde a los botones de la nueva interfaz de Firefox, parece que fue ayer que Australis llegaba a mis ojos, que nostalgia ver como evoluciona todo.

Quízá la llegue a portar a Google Chrome ( Eww ).

Pueden descargar la extensión en la siguiente URL

• https://addons.mozilla.org/es/firefox/addon/whitenoisefy/

Vaya sorpresa me lleve este fin de semana la plataforma que utilizaba para alojar el blog (Openshift 2) cerro para que todos migraran a su versión 3, actualmente no he publicado nuevas entradas en el blog pero si tenia algunos borradores que no pude salvar.

Si enviaron correos y dieron tiempo, pero yo solo los postergaba debido a que el trabajo me consume.

Por el momento decidí utilizar algunos créditos que tenia para Digital Ocean y ahora el blog esta alojado allí, mientras aprendo y veo como volver a alojarlo en Openshift 3.

El servicio de Digital Ocean es muy bueno, pude generar el blog en cuestión de minutos, pero para recuperar el contenido me di a la tarea de utilizar un backup antiguo que tenia por alli en Google Drive y gracias a mi cliente de RSS( Feedly) pude recuperar todo el contenido que no tenia respaldo.

También pase de Ghost 0.11.0 a 1.12.0, tenia que utilizar esa versión antigua ya que era un problema tratar de utilizar la nueva versión, debido al Nodejs que Openshift soporta, me dio una sorpresa encontrar que ahora ya no es posible pegar las urls de mi CDN directamente, es necesario instalar un plugin para tener algo parecido a la funcionalidad que tenia anteriormente, los desarrolladores de ghost comentaban que habían quitado la opción debido a que era un problema mantenerlo.

Con está versión de Ghost también se actualiza el tema por defecto llamado Casper, que no gusta, veré si encuentro uno, ahora es mas sencillo cambiar los temas, antes se tenia que reiniciar por completo el CMS.

Alojar mi blog en Digital Ocean solo durará aproximadamente 5 meses, espero poder echarlo a volar en Openshift, antes de ese tiempo.

Hasta hace algunos años siempre que se hablaba de montar un servidor web rondaba el nombre de Apache y por lo general era la opción inicial, ahora las cosas han cambiado y decidí recopilar información de fuentes confiables, traducirla al español, de por que Apache ya no es la mejor opción, al menos no de la antigua forma.

Apache es un servidor desarrollado en 1995, es una plataforma muy estable diseñada para ser extendida mediante módulos.

Los modulos de Apache lo proveen de muchas funcionalidades, entre ellas la posibilidad de servir contenido dinámico y ello dio paso a el stack XAMPP(Apache, MariaDB[Antes se usaba MySQL], PHP, Perl).

Apache esta diseñado para crear un thread/hilo por cada cliente que necesite ser atendido, este aislamiento ayudo a agilizar el desarrollo y la innovación.

La innovación trajo consigo un gran crecimiento en Internet y los usuarios comenzaron a crecer exponencialmente.

A su vez los componentes de las paginas comenzaron a ser mas y mas pesados y los usuarios menos pacientes al esperar que una pagina web cargue completamente.

Los cambios en el volumen de trafico de usuarios y páginas pesadas comenzaron a ser un desafío al modelo de un thread/hilo por usuario que tanto ayudo a Apache en un principio.

Sumado a eso comenzó a extenderse una practica llamada HTTP keepalive que permite disminuir el tiempo de carga de una página haciendo peticiones paralelas de los recursos, cada petición abierta es atendida por un proceso httpd, por esta razón Apache necesita crear numerosos procesos largos.

Para mejorar la portabilidad y escalabilidad en algunas plataformas, los principales desarrolladores de Apache crearon dos modelos de procesamiento adicionales (denominados módulos multiprocesamiento o MPM).

El MPM reemplazó los procesos separados de httpd con un pequeño número de procesos secundarios que ejecutaban múltiples subprocesos de trabajo y asignaban un subproceso por conexión. Esto fue útil en muchas versiones comerciales de Unix (como el AIX de IBM) donde los hilos son mucho más ligeros que los procesos, pero es menos efectivo en Linux donde los hilos y procesos son solo encarnaciones diferentes de la misma entidad del sistema operativo.

Más tarde, Apache añadió el event MPM, que amplía el MPM añadiendo un hilo escucha independiente que gestiona las conexiones de mantenimiento de inactividad una vez que la solicitud HTTP se ha completado.

Estas medidas sirven para mejorar el rendimiento, pero el modelo monolítico de un solo servidor que fue clave para el éxito temprano de Apache ha seguido luchando a medida que aumentan los niveles de tráfico y las páginas web se vuelven más y más pesadas.

El modelo pesado y monolítico de Apache tiene sus límites

El desempeño en los benchmarks de laboratorio a menudo no se reproduce en implementaciones de producción en vivo en sitios web ocupados y el ajuste de Apache para hacer frente al tráfico del mundo real es un arte complejo. De forma poco equitativa, Apache ha ganado una reputación como un servidor web hinchado, excesivamente complejo y limitado al rendimiento que puede ser explotado por ataques lentos de denegación de servicio (DoS).

Hasta aquí podemos saber un poco de historia de Internet como funcionan muchos de los servidores creados a día de hoy, ya que muchos utilizan Apache como base, sus problemas así como sus soluciones.

Introducción a NGINX - Diseñado para alta concurrencia

NGINX fue escrito específicamente para abordar las limitaciones de rendimiento de los servidores web Apache.

Fue creado en 2002 por Igor Sysoev, un administrador de sistemas para un popular sitio ruso (Rambler.ru), como una solución escalable para ayudar al sitio a administrar mayores y mayores volúmenes de tráfico.

Se convirtió en opensource en octubre de 2004, en el 47 aniversario del lanzamiento de Sputnik.

NGINX puede ser desplegado como un servidor web independiente, y como un proxy de frontend para Apache y otros servidores web.

Esta solución de despliegue actúa como un dispositivo de descarga de red frente a los servidores Apache, traduciendo las conexiones lentas del lado de Internet en conexiones rápidas y confiables del lado del servidor, y descargando completamente las conexiones keepalive de los servidores Apache.

El efecto neto es restaurar el rendimiento de Apache a niveles cercanos a los que los administradores ven en un punto de referencia local.

NGINX también actúa como un amortiguador de choque, protegiendo a los servidores vulnerables de Apache de picos en el tráfico y de ataques de conexión lenta como Slowloris y slowhttprequest.

El secreto en la arquitectura

El rendimiento y la escalabilidad de NGINX surgen de su arquitectura basada en eventos. Difiere significativamente del enfoque de proceso o hilo por conexión de Apache, en NGINX, cada proceso de trabajo puede manejar miles de conexiones HTTP simultáneamente. Esto resulta en una implementación considerada altamente como ligera, escalable y de alto rendimiento.

Para muchos tipos de aplicaciones, NGINX y Apache se complementan bien, por lo que suele ser más apropiado hablar de "NGINX y Apache" en lugar de "NGINX vs. Apache". Un patrón de inicio muy común es desplegar el software NGINX de código abierto como proxy (o NGINX Plus como plataforma de entrega de aplicaciones) frente a una aplicación web basada en Apache. NGINX realiza el levantamiento pesado relacionado con HTTP: sirve archivos estáticos, almacenamiento en caché de contenido y descarga de conexiones HTTP lentas, para que el servidor Apache pueda ejecutar el código de la aplicación en un entorno seguro.

NGINX proporciona todas las características principales de un servidor web, sin sacrificar las cualidades ligeras y de alto rendimiento que lo han hecho exitoso, y también puede servir como un proxy que reenvía las solicitudes HTTP a servidores web ascendentes (como un backend de Apache) y FastCGI, memcached, SCGI y uWSGI.

NGINX no busca implementar la enorme gama de funcionalidades necesarias para ejecutar una aplicación, sino que depende de servidores especializados de terceros como PHP-FPM, Node.js e incluso Apache.

“Apache is like Microsoft Word. It has a million options but you only need six. NGINX does those six things, and it does five of them 50 times faster than Apache.” — Chris Lea

Como podemos ver NGINX es un proyecto enfocado en la alta disponibilidad de los servicios, pero se enfoca en servir contenido estático y hacerla de proxy/conector entre otros servidores para darles mayor seguridad y ayudar a manejar el enorme trafico de usuarios.

Actualmente NGINX es utilizado por empresas como WIX, Wordpress y la NASA.

Es posible utilizar el soporte comunitario total mente gratis y también se tienen tres niveles de soporte de paga profesional ofrecido por NGINX, Inc.:

Básico ($1,900 US / year): Para los despliegues no críticos de NGINX en los que los tiempos de respuesta más largos son aceptables y no se requieren revisiones en caliente para implementaciones de producción.

Profesional ($3,000 US / year): Para el despliegue de producción de NGINX y NGINX Plus, o donde se requiera el manejo de casos prioritarios.

Enterprise ($4,500 US / year): Para despliegues de misión crítica de NGINX o NGINX Plus que requieren el nivel más alto de soporte con tiempos de respuesta más rápidos y soluciones a través de consultas telefónicas o web.

¿Qué cubre el soporte comercial de NGINX?

El uso de NGINX opensource y NGINX Plus

Búsqueda y corrección de errores.

Actualizaciones de software.

Asistencia con la instalación.

Notificaciones de seguridad.

Discrepancias en la documentación.

Conclusión:

Como podemos ver Apache como tal no esta muerto y no quiere decir que tengamos que dejar de utilizarlo y utilizar siempre NGINX, de hecho se recomienda utilizarlo junto con.

Simplemente es necesario combinarlo con los nuevos proyectos que están enfocados a solucionar problemas muy específicos en los cuales Apache o cualquier otro servidor no son buenos, en este caso NGINX, tiene los problemas más comunes de Apache resueltos pues así fue como nació.

También podemos ver que se tiene un soporte comercial y denota mucha madurez en el proyecto ya que es una empresa constituida y no es un proyecto que de la noche a la mañana pueda desaparecer, ver el peso y renombre de sus clientes da mucha confianza en ellos.

Fuentes:

https://www.nginx.com/blog/nginx-vs-apache-our-view/

Es posible iniciar imagenes de Docker de una forma muy sencilla con simplemente ejecutar un docker start contenedor, pero al tener un servicio ya en un servidor productivo al reiniciarse vamos a querer que este inicie automaticamente.

Para hacer esto con systemd(algunos lo odian, otros lo aman y otros tantos simplemente trabajan con el) es necesario crear un archivo y enviarlo a la carpeta /etc/systemd/system/ y habilitarlo.

Aquí muestro un ejemplo con un contenedor llamado nexus

Contenido del archivo :

[Unit]
Description=Nexus container  
Requires=docker.service  
After=docker.service

[Service]
Restart=always  
ExecStart=/usr/bin/docker start -a nexus  
ExecStop=/usr/bin/docker stop -t 2 nexus

[Install]
WantedBy=default.target

Comandos a ejecutar:

Creamos el archivo:

touch docker-nexus.service

Lo abrimos con nano y pegamos el contenido de arriba ya personalizado:

nano docker-nexus.service

copiamos el archivo a la carpeta especial de systemd:

sudo cp docker-nexus.service /etc/systemd/system/

Lo habilitamos:

systemctl enable docker-nexus.service

Al reiniciar nuestor SO debería de levantarse automaticamente nuestro contenedor.

Fuentes:

• https://docs.docker.com/engine/admin/host_integration/