Y es que a veces encontraremos que nuestra aplicación tiene unos requisitos mínimos que el servidor no cumple. Pongamos por ejemplo que queremos instalar prestashop que tiene ciertos requisitos mínimos y que por algún motivo nuestro hosting no satisface.

Cómo configurar variables de PHP desde .htaccess

Hay varias formas de actuar sobre estas variables, pero tal y como reza el título de esta entrada hoy vamos a hacerlo con el archivo .htaccess, y para ello utilizaremos la orden php_value. Su sintaxis es muy sencilla:

php_value + variable_php + valor.

Un ejemplo podría ser que necesitamos que la variable memory_limit esté configurada en 64M y el servidor la tiene configurada en 32M, o quizás el max_input_vars está configurado en 500 y nuestros requisitos mínimos son 1.000. Para ello incluiríamos las siguientes líneas en el archivo .htaccess:

php_value memory_limit 64M
php_value max_input_vars 1000

O supongamos que queremos mostrar los errores de PHP de nuestra aplicación. Podemos hacerlo desde el archivo .htaccess:

php_value error_reporting 7
php_flag display_errors On

Dónde colocar las líneas dentro del archivo .htaccess

Personalmente me gusta colocar este tipo de sentencias al comienzo del archivo .htaccess, justo detrás de los comentarios:

# Comentarios habituales en archivos .htaccess

# variables php
php_value error_reporting 7
php_flag display_errors On

<IfModule mod_rewrite.c>
<IfModule mod_env.c>
SetEnv HTTP_MOD_REWRITE On
</IfModule>

RewriteEngine on
...

Créditos, referencias y artículos relacionados

• Aumentar el límite de memoria de un script en PHP
• Aumentar el limite de tiempo máximo de ejecución de un script en PHP
• Servidor Web en Raspberry PI y Ubuntu Mate
• Como configurar Virtual Hosts en Apache 2 y Ubuntu
• Habilitar módulos en Apache 2 sobre Ubuntu

Para concluir con la serie de artículos relacionados con la instalación de Prestashop 1.7 vamos a aprender a verificar si cumplimos con todos los requisitos de sistemas, tanto los mínimos como los recomendados.

Y para ponerte en situación recuerda que ya hemos visto cómo instalar Prestashop 1.7 y también los requisitos mínimos de Prestashop 1.7.

Por qué verificar los requisitos mínimos Prestashop 1.7

En una instalación nueva el propio asistente de instalación realiza las comprobaciones oportunas y nos indica si existe algún requisito no satisfecho. Así que este artículo no tendría mucho sentido.

Pero no siempre realizamos una instalación desde 0, y verificar si cumplimos con los requisitos mínimos de Prestashop es especialmente útil cuando migramos una tienda existente o montamos un entorno de desarrollo o de pre-producción desde una tienda existente.

Cómo verificar los requisitos mínimos Prestashop 1.7

Para esta verificación utilizaremos la herramienta PhpPsInfo – PrestaShop system requirements checker. Los pasos a seguir son pocos y sencillos:

1. Descarga la última versión de la herramienta PhpPsInfo desde GitHub.
2. Descomprímela.
3. Copia el archivo phppsinfo.php en la carpeta raíz de Prestashop.
4. Accede al archivo desde tu navegador (http://url-a-tu-prestashop/phppsinfo.php).
5. Cuando pida usuario y contraseña usa «prestashop» en ambos, sin comillas.

Si lo hemos hecho correctamente accederemos a una página que nos indica si cumplimos o no con los requisitos mínimos y recomendados.

Créditos, referencias y artículos relacionados

• Instalar Prestashop 1.7
• Requisitos mínimos de Prestashop 1.7
• Archivos y permisos de usuario en Apache 2 y Linux

Hace ya algún tiempo escribimos el artículo Instalar Prestashop 1.7. En él hacíamos referencia a los requisitos necesarios para instalar Prestashop sin entrar en demasiado detalle. En esta entrada vamos a profundizar en este tema.

Requisitos mínimos y recomendados de Prestashop 1.7

Repasaremos la lista de requisitos agrupándolos en varios conceptos. Si quieres irte a la fuente oficial de la información échale un vistazo a la página de System Requirements for Prestashop.

Requisitos generales

Veamos en primer lugar la lista de requisitos generales para poder correr prestashop 1.7 en una máquina.

Módulos de Apache

Es recomendable activar algunos módulos de Apache, aunque es posible pasar sin ellos.

Extensiones de PHP

Un aspecto fundamental es asegurarnos de que tenemos activadas todas las extensiones de PHP necesarias.

Configuración de PHP

También debemos garantizar la correcta configuración de algunas variables de PHP.

Directorios con necesidad de permisos de escritura

Por último, debemos asignar permisos de escritura a ciertos directorios. Recuerda que ya hemos visto como asignar permisos en el artículo Archivos y permisos de usuario en Apache 2 y Linux.

La lista de directorios que deben tener permisos de escritura son los siguientes:

Créditos, referencias y artículos relacionados

• Instalar Prestashop 1.7
• Cómo verificar los requisitos mínimos de Prestashop 1.7
• Archivos y permisos de usuario en Apache 2 y Linux

En caso de que todavía no hayas utilizado esta plataforma puedes acceder a una demo en este enlace. También puedes echar un vistazo al articulo Plataformas ecommerce open source para valorar otras alternativas.

Requisitos previos

Antes de comenzar a instalar Prestashop deberemos asegurarnos de cumplir algunos requisitos de software:

• Servidor web Apache 2.x o Nginx.
• PHP 5.6 o superior.
• MySQL 5.0 o superior.
• Acceso FTP (o en su defecto al directorio donde se va a instalar si es en local).

Y en cuanto a la configuración de PHP necesitaremos:

• Habilitar las extensiones Mcrypt, OpenSSL, Zip, Curl, GD y PDO.
• Establecer un valor de «128M» o mas en el parámetro memory_limit. Puede ver como hacerlo en la entrada Aumentar el límite de memoria de un script en PHP.
• Establecer upload_max_filesize, en «16M».

Y por supuesto, en el entorno de produccion necesitaras un certificado SSL. El equipo detrás de Prestashop también recomienda MemCached, Apc o OpCache para mejorar el rendimiento.

Tienes mucha más información sobre los requisitos mínimos en el artículo requisitos mínimos de Prestashop 1.7.

El entorno de este ejemplo

En este ejemplo instalaremos Prestashop en un entorno de pruebas, sobre una Raspberry Pi 3 Model B, corriendo Ubuntu Mate 16.04.6, Apache 2.4.18, PHP 7.0.33-6 y Maria DB 10.0.38.

Yo he creado un host virtual para la instalación, puedes ver como hacerlo en la entrada Como configurar Virtual Hosts en Apache 2 y Ubuntu, aunque esto dependerá de tus necesidades.

En mi caso el host virtual se encuentra bajo el directorio /var/www/prestashop/public y accederé mediante la url http://192.168.1.10:8086.

Instalar Prestashop

Ahora que ya tenemos todo preparado para la instalación vayamos al lío.

Descarga, descompresión y subida al servidor

Descargaremos Prestashop desde este enlace. En nuestro caso el nombre del archivo es prestashop_1.7.6.3.zip. Una vez descargado lo descomprimimos y obtenemos tres archivos: index.php, Install_PrestaShop.html y prestashop.zip.

Colocamos estos tres archivos en nuestro servidor. Si trabajas en un servidor local será tan sencillo como copiarlos o moverlos. En caso de trabajar sobre un servidor remoto la opción más habitual suele ser cargarlos con un cliente FTP.

Comienzo de la instalación

Para comenzar la instalación abriremos un navegador web y accederemos la URL dónde hemos subido nuestros archivos, en este ejemplo: http://192.168.1.10:8086.

Llegados a este punto, el instalador comprueba una serie de pre-requisitos, y en caso de no haber cumplido con alguno de ellos obtendremos un mensaje de error.

En la galería al pie del artículo puedes ver un ejemplo dónde nos indica que falta una extensión de PHP: An error has occured: You must install PHP zip extension first.

Si este fuera nuestro caso recargaremos la página una vez satisfecho el requisito.

Asistente de instalación

Una vez iniciado el proceso tan solo tendremos que ir avanzando a través de los distintos pasos del asistente de instalación. Tienes pantallazos de todos ellos al pie de este artículo. Los pasos son los siguientes:

1. Selección de idioma.
2. Lectura y aceptación de licencia (si estás de acuerdo).
3. Validaciones de sistema. Antes de continuar con el proceso, el instalador realiza una serie de verificaciones a fin de asegurar que cumplimos todos los requisitos necesarios para el correcto funcionamiento de Prestashop. En caso de no superar la validación deberemos subsanar el problema para poder continuar.
4. Introducción de los datos de la tienda. Entre otros el nombre de la tienda, el tipo de actividad, el nombre de usuario del administrador, la contraseña de administrador, etc.
5. Configuración de la conexión a la base de datos. Para lo que tendremos que haber creado una base de datos vacía previamente.
6. Proceso de instalación. La habitual barra de proceso que finaliza con un mensaje de éxito (o no).
7. Eliminación de la carpeta de instalación. Por motivos de seguridad debemos realizar un último paso para completar la instalación. Éste consiste en eliminar la carpeta install del directorio raíz de nuestro prestashop.

Acceso a la tienda

Una vez concluida la instalación podremos ver cómo luce nuestra tienda accediendo a la URL dónde la hemos instalado. En mi caso http://192.168.1.10:8086.

Veremos el tema por defecto de Prestashop en una tienda que a falta de configuración es totalmente funcional.

Acceso al panel de administración

Para acceder al panel de administración lo haremos con la misma URL con la que accedemos a la tiendas seguida de /admin, es decir, en mi caso http://192.168.1.10:8086/admin.

Por seguridad, tras el primer acceso a esta dirección, Prestashop cambia el nombre a la carpeta admin por uno aleatorio. Una práctica habitual es volver a renombrar esa carpeta con un nombre más sencillo de recordad pero no tan evidente como: admin, backoffice, back, panel, etc.

Para acceder al backoffice, es requisito indispensable haber borrado la carpeta install. Si no lo hemos hecho recibiremos el siguiente mensaje de advertencia impidiéndonos la autentificación: «Por razones de seguridad, no te puedes conectar al back-office hasta que tengas eliminado la carpeta /install».

Pantallazos

A continuación tenéis los pantallazos de todos los pasos seguidos.

Creditos, referencias y articulos relacionados

• Plataformas ecommerce open source
• Requisitos mínimos de Prestashop 1.7
• Cómo verificar los requisitos mínimos de Prestashop 1.7
• 5 factores clave para el éxito de cualquier página web
• Como configurar Virtual Hosts en Apache 2 y Ubuntu
• Aumentar el límite de memoria de un script en PHP

Definición de mantenimiento

Antes de avanzar con los distintos tipos de mantenimiento, es buena idea unificar criterios y asegurarnos de que estamos de acuerdo en la definición.

El mantenimiento es la acción de modificar la versión en producción software con el fin de corregir errores, subsanar problemas o realizar cambios enfocados en conservar la capacidad de prestar el servicio para el cual fue diseñado.

Tipos de mantenimiento

Y ahora que tenemos claro qué es el mantenimiento del software, repasemos qué tipos hay.

Mantenimiento preventivo

Si visualizamos el mantenimiento desde un prisma general y no solo desde el punto de vista del desarrollo de software, la mayoría de nosotros pensaremos en un conjunto de acciones proactivas enfocadas a evitar el deterioro de la cosa mantenida.

Si hablamos de software es exactamente igual, el mantenimiento preventivo es la acción de modificar el software proactivamente con el objetivo de evitar su deterioro o de mejorarlo sin alterar su funcionamiento.

Podemos realizar este tipo de mantenimiento por varios fines como corregir olores en el código, mejorar la comprensión, optimizar el funcionamiento, optimizar el consumo de recursos, etc

Llegados a este punto quizás te estés preguntando cuál es la diferencia entre el mantenimiento preventivo y la refactorización, pues a mi modo de ver ninguna, son la misma cosa. Así que te invito a leer el artículo Refactorización de código para ampliar conocimientos.

Mantenimiento correctivo

El mantenimiento correctivo se sitúa justo en el lado opuesto del mantenimiento preventivo: si en el mantenimiento preventivo actuamos de forma proactiva para evitar que se produzca el error, en el mantenimiento correctivo lo hacemos de forma reactiva y reaccionamos a los o errores que aparecen.

Los errores son inevitables y por más que intentemos desarrollar software libres de bugs, tarde o temprano y en mayor o menor medida éstos van a aparecer. Por lo tanto, para minimizar el tiempo que invertimos gastamos corrigiendo errores y sufriendo los efecto de sus consecuencias debemos enfocar nuestros esfuerzos en tres tareas:

• Disponer de un proceso de desarrollo adecuado con el fin de minimizar el número de bugs desde el primer momento. Puedes echarle un vistazo a la entrada entorno de desarrollo.
• Realizar mantenimiento preventivo (ó refactorización).
• Disponer de herramientas adecuadas para la notificación, clasificación y seguimiento de los errores.

Mantenimiento adaptativo

El mantenimiento adaptativo consiste en modificar el software, sin alterar su funcionamiento, con el objetivo de dar respuesta a cambios en el entorno de la aplicación. El objetivo es que estos cambios no afecten a la capacidad del programa de prestar el servicio.

Algunos ejemplos de este tipo de mantenimiento pueden ser:

• Modificar el software para adaptarse a cambios en una API de terceros.
• Adaptar un software para soportar una nueva versión del lenguaje de programación.
• Actualizar la versión de una librería o de un framework.
• Soportar cambios en el sistema operativo o en el hardware.

Mantenimiento perfectivo

En la literatura que he consultado identifican el mantenimiento perfectivo como un tipo de mantenimiento con un doble objetivo: por un lado la incorporación de nuevas funcionalidades o la modificación de las existentes, y por otro las adaptaciones necesarias para asegurar el rendimiento cuando existe un incremento del volumen considerable.

Mi opinión es que teniendo en cuenta el auge de los modelos de desarrollo ágiles y su filosofía de entrega de valor rápida basada en ciclos de desarrollo cortos, el mantenimiento perfectivo queda absorvido por la propia fase de desarrollo.

Y en cuanto a las adaptaciones necesarias para asegurar el rendimiento por aumento de volumen, creo que pueden ser perfectamente incluidas como mantenimiento preventivo, si se atajan a tiempo, o en caso contrario como mantenimiento correctivo.

Dónde comienza el mantenimiento

La versión en producción de un software es el producto de un proceso complejo formado por varias etapas conocido cómo ciclo de vida del software. Por lo tanto, la calidad del software final está altamente condicionada por la calidad individual de cada una de las etapas.

Por lo tanto, con el fin de minimizar el esfuerzo que hacemos en mantener el software podemos dar por válida una pequeña mentira: el mantenimiento del software comienza en el mismo momento en el que comienza el análisis de viabilidad del software. Es decir, invertir el tiempo necesario y hacer las cosas bien en cada una de las etapas nos garantiza, entre otras muchas ventajas, gastar menos tiempo en el mantenimiento del software .

Mantenimiento, evolución y metodologías ágiles

Como hemos visto con el mantenimiento perfectivo, las metodologías ágiles hacen que los conceptos de mantenimiento y evolución, en algunos casos, estén separados por una delgada línea gris que invita a hacer interpretaciones subjetivas de qué es qué. Éste es un tema sobre el que podríamos escribir largo y tendido, y sobre el que en esta ocasión no vamos a entrar pero si creí necesario mencionar.

Créditos, referencias y artículos relacionados

• Imagen de portada por Steve Buissinne en Pixabay
• Guía del buen programador
• Deuda tecnológica o deuda técnica
• Refactorización de código
• Cohesión y acoplamiento

Personalmente lo utilzo con relativa frecuencia, generalmente con el cliente FileZilla, un cliente FTP multiplataforma de código abierto muy recomendable. Y siendo honestos, hasta la escritura de esta entrada, mi desconocimiento sobre los modos de conexión activo o pasivo era absoluto, algo que intuyo que le sucede a mucha gente, y ya se sabe que mal de muchos consuelo de tontos entrada en el blog.

FTP, FTPS y SFTP.

Recordemos que existen tres protocolos distintos a los que solemos referirnos cuando hablamos de FTP: FTP, FTPS y SFTP. Si tienes dudas sobre alguno de ellos puedes echarle un vistazo a la entrada FTP, FTPS y SFTP: diferencias, ventajas e inconvenientes.

Pues bien, los modos activo o pasivo solo aplican sobre los protocolos FTP y FTPS, en ningún caso sobre SFTP, pues es un protocolo que dista bastante de los dos anteriores.

Puerto de datos y puerto de control

Otro aspecto clave que debemos conoce para entender el funcionamiento del FTP es que trabaja sobre dos puertos distintos: el puerto de datos y el puerto de comandos o puerto de control.

Los nombres son bastante auto-explicativos, el puerto de datos se encarga de la transmisión de los ficheros y el puerto de control de las instrucciones entre ambos host. Se diseñó así para poder enviar comandos sin la necesidad de detener la transmisión de datos ni de encolarlos tras estos.

Si nos centramos en el servidor, tradicionalmente el puerto de control ha sido el 21 y el puerto de datos varía en función del modo, siendo el 20 para el modo activo, y un puerto aleatorio para el modo pasivo.

En el lado del cliente, en cambio, el puerto de control será un puerto aleatorio P superior a 1023, y el puerto de datos será P+1. Esto es así tanto en el modo activo, como en el pasivo.

Pero veamos cada uno de los modos en detalle para entenderlo mejor.

FTP activo

Es el modo predeterminado para las conexiones FTP, de hecho fue el primero en desarrollarse. En este modo el servidor utilizará el puerto 20 para la transferencia de datos, mientras que transmitirá los comandos utilizando el puerto 21. El cliente en cambio utilizará un puerto aleatorio P superior al 1023 para la transferencia de comandos, y un puerto P+1 para la transferencia de datos.

Secuencia de conexión del modo activo

La secuencia de conexión del modo activo es la siguiente:

1. El cliente FTP comienza la conexión dese un puerto de control aleatorio P con destino al puerto 21 del servidor. Como hemos mencionado el puerto P será superior a 1023.
2. El servidor responde desde el puerto de control.
3. El servidor inicia entonces la conexión del canal de datos: puerto 20 para el servidor y puerto P+1 para el cliente.
4. El cliente responde desde el puerto de datos estableciendo así la conexión.

Inconvenientes del modo activo

Históricamente el principal inconveniente de este modo ha radicado en que si no hay una directiva específica en los firewalls del lado del cliente, la conexión es propensa a ser bloqueada. Esto se debe a que, como hemos visto, existen dos conexiones independientes: una de salida en la que el cliente establece la conexión del canal de control y otra de entrada en la que el servidor hace lo propio con el de datos. Esta última conexión es iniciada por el servidor en el puerto previamente negociado, y en ocasiones es bloqueada por el firewall del cliente al ser identificada como un intento de conexión externa no autorizada.

Recordemos que este sistema se diseñó en los años 70, cuando la democratización de los sistemas informáticos y los problemas de seguridad eran completamente distintos a los que podemos encontrar hoy en día.

Sea como sea, en todos los años que llevo utilizando el protocolo FTP desde el rol de cliente, no recuerdo haber experimentado nunca problemas de este tipo, y habré conectado con varias decenas de servidores de muchos proveedores distintos. Entiendo que esto se deba a la sofisticación de los sistemas de red y de seguridad más modernos.

FTP pasivo

El modo de FTP pasivo surge como consecuencia de los problemas de conexión del modo activo. Este modo mantiene los dos canales (control y datos) pero en este caso es el cliente el encargado de establecer las dos conexiones.

El servidor sigue manteniendo el puerto 21 como puerto de comandos, el puerto de datos en cambio difiere del modo activo y pasa a ser un rango de puertos Q superior a 1023. Del lado del cliente seguimos manteniendo el puerto P superior a 1023 para control, y el puerto P+1 para datos.

Secuencia de conexión del modo pasivo

La secuencia de conexión del modo pasivo es la que sigue a continuación:

1. El cliente FTP comienza la conexión dese un puerto de control aleatorio P con destino al puerto 21 del servidor.
2. El servidor responde desde el puerto de control.
3. El cliente inicia la conexión del canal de datos dese el puerto P+1 hacia el puerto Q del servidor.
4. El servidor responde desde el puerto de datos estableciendo así la conexión.

Como ves, los pasos uno y dos son iguales que en el modo activo, y es en los pasos tres y cuatro dónde vemos como se invierten los roles y es el cliente el que inicia la conexión de datos.

Inconvenientes del modo pasivo del FTP

El principal inconveniente de habilitar el modo pasivo en un servidor FTP está asociado con el riesgo extra en materia de seguridad que conlleva la apertura de un rango de puertos extra con respecto al modo activo. Notemos que para que el modo pasivo funcione adecuadamente estos puertos deben ser abiertos tanto en el servidor como en el firewall.

Para minimizar este riesgo la estrategia pasa por definir un rango de puertos lo más pequeño posible en función del número de conexiones concurrentes que esperemos tener, pero ojo, porque un cliente no se corresponde con una única conexión, es muy probable que cada cliente abra múltiples conexiones concurrentes.

Resumen

Para cerrar esta entrada os dejo una tabla con el resumen de lo que hemos visto.

Créditos, referencias y artículos relacionados

• Imagen de portada por Michal Jarmoluk en Pixabay
• FTP, FTPS y SFTP: diferencias, ventajas e inconvenientes
• VSFTP instalar y configurar un servidor FTP en una Raspberry Pi con Ubuntu
• FTPS o cómo habilitar SSL en vsftp
• Usuarios virtuales en vsftp

La primera de ellas es una sección de lo más habitual en muchos blogs. Hablamos de la sección Blog Roll, algo que le hacía mucha falta a este blog como parte del objetivo social que quiero que cumpla.

La segunda sección la he llamado La guía del buen programador, y no es más que una colección ordenada de enlaces a publicaciones de este blog relacionadas con la parte más conceptual de la programación, la calidad del software y las buenas prácticas. De forma que a pesar de ser artículos independientes, trazamos un hilo conductor entre ellos para para formar un ente de mayor tamaño, una guía.

Dejo enlaces a ambas secciones en la barra lateral.

Créditos, referencias y artículos relacionados

• Imagen de portada por Free-Photos en Pixabay
• Blog Roll
• La guía del buen programador

A mi modo de ver, estos tres principios pueden ser tratados como tres magníficos consejos para compartir con los desarrolladores más noveles, e incluso a veces con algunos mucho más experimentados.

KISS

KISS es un principio de diseño muy popular tanto en el desarrollo de software como en otros muchos ámbitos. Es el acrónimo de «Keep It Simple, Stupid», y es una forma coloquial de decir que las cosas sencillas funcionan mejor.

Es uno de los mejores consejos se le puede dar a cualquier persona que diseñe o cree algo, ya sea relacionado con el desarrollo del software o no: hazlo sencillo, evita complicaciones innecesarias.

Y ya centrándonos en el desarrollo de software, evitar aumentar el nivel de complejidad cuando no es estrictamente necesario trae consigo múltiples ventajas, entre las que destacar la mejora de la comprensión y el mantenimiento, sin olvidar la sensación de satisfacción de haber escrito un código elegante.

No seguir este principio, en cambio, propiciará tener una estructura y un código engorroso y con olores. Si eres lector habitual de este blog, recordarás que hace varios meses escribíamos sobre el código limpio en el artículo ¿A qué huele el código fuente?, dónde mencionábamos la complejidad innecesaria como un motivo de olor.

A modo anecdótico añadir que KISS es un principio que no proviene del desarrollo de software, su origen se atribuye al ingeniero aeroespacial americano Kelly Jonhson, quien contribuyó al desarrollo de varias aeronaves para el ejército de su país.

DRY

DRY hace énfasis en la importancia de evitar la duplicidad en el código fuente, siendo el acrónimo de «Don’t repeat yourself» y estando sustentado por la afirmación de que cada pedazo de código debe tener una representación única, inequívoca y autoritaria en el sistema.

Los padres de DRY son Andy Hunt y Dave Thomas, quienes publicaron este principio en el libro The Pragmatic Programmer, en 1999, y del que en el momento de escribir estas líneas han publicado una edición conmemorativa del veinte aniversario.

Es un principio que está estrechamente ligado con la calidad del código y que, al igual que sucede con KISS, también mencionamos en el artículo ¿A qué huele el código fuente?.

Y cuando no cumplimos con el principio DRY, se suele decir que cumplimos con el principio WET, por el juego de palabras en inglés, dónde WET sería el acrónimo de «write every time» o «we enjoy typing».

YAGNI

Tercer principio, tercer consejo y para cerrar el círculo tercer acrónimo, en este caso de «You aren’t gonna need it».

Este principio invita a no desarrollar «por si a caso», ¿cuantas veces nos han pedido una funcionalidad determinada y hemos excedido los requisitos en previsión de algo que nunca ocurrió? Pues bien, YAGNI propone hacer exclusivamente lo solicitado y necesario.

YAGNI tiene su origen en la programación extrema, dónde prima la simplicidad y dónde se opta por no invertir tiempo en dar solución a necesidades todavía inexistentes. La programación extrema se guían por la afirmación «Do The Simplest Thing That Could Possibly Work», de la cual han creado un acrónimo DTSTTCPW que desde mi punto de vista excede lo razonable y roza el absurdo.

Este principio es sin duda alguna el que más me ha costado aceptar de los tres que hemos visto hoy, de hecho, aunque estoy muy de acuerdo con él y creo que por norma general deberíamos cumplirlo, considero que la intuición de un desarrollador o un analista suficientemente experimentado, en combinación de un profundo conocimiento del negocio y del cliente, pueden dar pie a que nos saltemos este principio en ocasiones puntuales.

Créditos, referencias y artículos relacionados

• Imagen por Inactive Account en Pixabay.
• ¿A qué huele el código fuente?
• Patrones de diseño de software
• Refactorización de código
• Cohesión y acoplamiento
• Deuda tecnológica o deuda técnica

Qué son los patrones de diseño

La RAE define patrón como un «Modelo que sirve de muestra para sacar otra cosa igual», una definición muy acertada si la aplicamos al diseño de software.

Los patrones de diseño de software son un conjunto de estrategias de programación diseñadas para dar solución a problemas comunes. Cada patrón se centra en resolver un problema determinado, de forma que disponemos de una solución estándar que garantiza la resolución eficaz de un problema particular.

Podemos decir que existe un catálogo de patrones de diseño de software, aunque hasta dónde he podido investigar, no existe una lista oficial, pero si una serie de comunidades y organizaciones enfocadas en la investigación, aprendizaje, inventariado y comunicación de las mismas. Entre ellas podemos destacar The Hillside Group.

Otro aspecto más a destacar es que los patrones de diseño no son un ente estático, sino que evolucionan atendiendo a los nuevos retos que surgen con los avances en el área de la programación. Así, vemos como cada cierto tiempo se amplia el catálogo de patrones con algunos nuevos.

Un poco de historia

Podemos decir que los patrones de diseño fueron popularizados en la década de los noventa por un grupo de programadores conocido como ‘Gang of Four’ formada por: Erich Gamma, Richard Helm, Ralph Johnson y John Vlissides.

La banda de los cuatro, traducción de Gang of Four, publicaron el libro ‘GoF Design Patterns’ en el año 1990. No obstante, debemos destacar que no fueron los primeros en acuñar el término.

El libro ‘GoF Designa Patterns’ está disponible en OpenLibra bajo licencia Creative Commons Attribution-ShareAlike 3.0.

Beneficios de los patrones de diseño

Estandarizar la estrategia de resolución de algunos problemas comunes aporta varios beneficios, estos son algunos de ellos:

• Ahorro de tiempo en el planteamiento y el diseño de la solución, pues no es necesario reinventar la rueda.
• Existencia de extensa documentación.
• Resultados previsibles y garantizados.
• Traspaso ágil de conocimientos.
• Estandarización de vocabulario.
• Facilidad para obtener soporte comunitario.

Tipos de patrones de diseño

El libro ‘GoF Design Patterns’, definía un total de 23 patrones divididos en tres categorías, pero desde su publicación han pasado casi treinta años, y como hemos comentado hablamos de un ente en constante evolución, así que tanto el numero de patrones como el número de tipologías en los que están segmentados han crecido considerablemente. A día de hoy, podemos dividir los patrones en las siguientes categorías:

• Patrones creacionales
• Patrones estructurales
• Patrones de comportamiento
• Patrones funcionales
• Patrones de concurrencia
• Patrones de arquitectura
• Patrones de computación distribuida
• Otros

De las cuales las tres primeras eran las que aparecían en el libro ‘GoF Design Patterns’.

Patrones de diseño

A pesar de no existir un catálogo oficial, a continuación veremos una lista de los principales patrones segmentados según las distintas tipologías que hemos visto.

Pensaba acompañar cada patrón de una breve descripción, pero teniendo en cuenta que mencionaremos más de cien, no acabaría nunca de escribir esta entrada. Así pues, tomaremos esta entrada como introducción e índice para futuros artículos dedicados a patrones de diseño específicos.

Los nombres de los patrones los especificaremos en inglés, aunque muchos de ellos tienen su traducción en castellano.

Patrones de diseño creacionales

• Abstract factory
• Builder
• Dependency injection
• Factory method
• Lazy initialization
• Multiton
• Object pool
• Prototype
• RAII
• Singleton

Patrones de diseño estructural

• Adapter
• Bridge
• Composite
• Decorator
• Delegation
• Facade
• Flyweight
• Front controller
• Marker interface
• Module
• Proxy
• Twin

Patrones de diseño de comportamiento

• Blackboard
• Chain of responsibility
• Command
• Interpreter
• Iterator
• Mediator
• Memento
• Null object
• Observer
• Servant
• Specification
• State
• Strategy
• Template method
• Visitor

Patrones de diseño funcional

• Closure
• Currying
• Function composition
• Functor
• Monad
• Generator

Patrones de diseño de concurrencia

• Active object
• Actor
• Balking
• Barrier
• Binding properties
• Coroutine
• Compute kernel
• Double-checked locking
• Event-based asynchronous
• Fiber
• Futex
• Futures and promises
• Guarded suspension
• Immutable object
• Join
• Lock
• Messaging
• Monitor
• Nuclear
• Proactor
• Reactor
• Read write lock
• Scheduler
• Thread pool
• Thread-local storage

Patrones de diseño de arquitectura

• ADR
• Active record
• Broker
• Client–server
• CBD
• DAO
• DTO
• DDD
• ECB
• ECS
• EDA
• Front controller
• Identity map
• Interceptor
• Implicit invocation
• Inversion of control
• Model 2
• MOM
• Microservices
• MVA
• MVC
• MVP
• MVVM
• Monolithic
• Multitier
• Naked objects
• ORB
• P2P
• Publish–subscribe
• PAC
• REST
• SOA
• Service locator
• SN
• SBA
• Specification

Patrones de diseño de computación distribuida

• Ambassador
• Anti-Corruption Layer
• Bulkhead
• Cache-Aside
• Circuit Breaker
• CQRS
• Compensating Transaction
• Competing Consumers
• Compute Resource Consolidation
• Event Sourcing
• External Configuration Store
• Federated Identity
• Gatekeeper
• Index Table
• Leader Election
• MapReduce
• Materialized View
• Pipes
• Filters
• Priority Queue
• Publisher-Subscriber
• Queue-Based Load Leveling
• Retry
• Scheduler Agent Supervisor
• Sharding
• Sidecar
• Strangler
• Throttling
• Valet Key

Otros patrones de diseño

• Business delegate
• Composite entity
• Intercepting filter
• Lazy loading
• Mangler
• Mock object
• Type tunnel
• Method chaining

Créditos, referencias y artículos relacionados

• Imagen por stux en pixabay
• ¿A qué huele el código fuente?
• Refactorización de código
• Cohesión y acoplamiento
• Deuda tecnológica o deuda técnica

Como era de esperar, hoy ese ímpetu inicial ha dejado paso a una evolución más reflexiva, y que mejor oportunidad que esta fecha para hacer una pequeña retrospectiva y pensar en lo que nos deparará este segundo año de vida que iniciamos con esta entrada.

Contenido

Inicié el primer año planteándolo como un año de prueba, proponiéndome un objetivo muy humilde: sobrevivir al primer año con una cadencia de publicación mínima de una publicación cada dos semanas.

Con 46 piezas publicadas he sido capaz de superar este objetivo puramente cuantitativo. Pero siendo honesto conmigo mismo existen varias entradas que tras revisarlas a posteriori no superarían el estándar mínimo de calidad que me he autoimpuesto.

Y continuando con lo que a calidad de contenido se refiere, me ha sorprendido mucho que una gran cantidad de los artículos que considero de mayor interés y calidad no son los que más visitas tienen, es más, en algunos casos tienen muy pocas visitas.

Comentarios

Una de las razones que me motivó a enrolarme en esta empresa era la de compartir con personas con aficiones o profesiones afines, entendido el término compartir como una conversación y no como un discurso.

La realidad es que, al menos en este primer año, no lo he conseguido, y la lectura que hago en este apartado es que debo ser yo quién inicie la comunicación en otros sitios en lugar de esperar que se inicie aquí.

Estadísticas de tráfico

El número de visitas es muy modesto. La parte positiva es que tal y como es de esperar en una web de reciente creación, los números mejoran notablemente mes a mes, en este caso en doble dígito.

Un dato que me ha resultado muy curioso es que al contrario de la tendencia que está tomando internet, el 92% de las visitas provienen de ordenadores y tan solo un 7% lo hacen desde móviles. Entiendo que el motivo es la temática del blog.

Algunas datos más que me gustaría compartir con vosotros son:

• El 30% de vosotros visitáis este blog desde un ordenador con Linux.
• Visitáis el blog desde: España 25%, México 15%, Colombia 9%, Argentina 9%, Perú 7%, Chile 6%, EEUU 5%, y así hasta un total de 25 países distintos. Realmente contento con este dato, no lo habría imaginado.
• Solo el 16% de vosotras sois mujeres.
• Solo el 4% de vosotros superáis los 55 años.

Asignaturas pendientes

Este ha sido un año de arranque en el que he hecho muchas cosas, pero también han quedado muchas sin hacerse, os cuento algunas de ellas.

• SEO Offsite. El SEO es uno de los aspectos que prácticamente no he tocado este primer año.
• Twitter. Twitter es un complemento perfecto para un blog como este, pero es una red social que siempre se me ha atragantado.
• Establecer una rutina de publicación constante.

Por supuesto que no son las únicas, hay muchas más, pero son las tres que hoy por hoy destacaría.

Lo que viene

Tengo una idea bastante clara de lo que quiero hacer durante este segundo año de vida del blog, pero prefiero no contároslo por varios motivos:

1. Crear y escribir este blog es básicamente una afición, y compartir mis planes generaría unas expectativas que conociéndome me auto obligaría a cumplir. Y no me apetece.
2. A pesar de que tengo una visión bastante clara de a dónde quiero llegar, mantengo un planteamiento de startup que me permite pivotar en lo táctico.
3. Si os adelanto las novedades, no tendrían ninguna gracia.

Pero la parte más importante que seguro que habéis intuido o incluso dado por hecho, es que el principal objetivo de este segundo año es continuar escribiendo y mantener el blog activo al menos un año más.

Valoración subjetiva de este primer año

Cierro esta entrada compartiendo con vosotros los dos aspectos que destacaría tras este primer año de vida del blog. Y como no todo es de color de rosas, os contaré lo mejor y lo peor.

En primer lugar hablemos del punto menos positivo. Gestionar un blog, que no solo escribir, consume mucho tiempo, y cuando no te sobra estás obligado a realizar sacrificios constantes para encontrarlo.

En cuanto al aspecto más dulce, a pesar de que pueda parecer un tópico, destacaría la ilusión de ver nacer y crecer un proyecto personal.

Y aprovecho este último párrafo para invitarte a que dejes un comentario si eres un lector habitual de este blog, es muy gratificante saber que otra persona valora tu trabajo.

Créditos

• Imagen de portada: S. Hermann & F. Richter en Pixabay en Pixabay
• Este fue el primero: ¡Hola Mundo!