SOLID

 El termino SOLID es un acronimo acuñado por el gran Robert C. Martin a comienzos del 2000, este acronimo define segun Robert C. Martin cinco principios fundamentales a seguir para que un software diseñado con el paradigma orientado a objetos sea facil de mantener y pueda soportar cambios en el tiempo.

El acronimo SOLID resume lo siguiente:

• S - Single Responsability Principle - Principio de responsabilidad única, esto quiere decir que al diseñar una clase la misma solo debe tener una responsabilidad, si la responsabilidad que se le quiere asignar no va con el diseño original esto nos quiere decir indirectamente que estamos por cometer un error al asignar otra responsabilidad a nuestra clase original.
• O - Open Closed Principle - Las clases tienen que diseñarse de forma abierta para ser extendida pero cerrada para las modificaciones.
• L - Liskov substitution Principle - Funciones que usan punteros o referencias a clases padres deben ser capaces de usar objetos de clases derivadas sin conocerlas.
• I - Interface segregation principle - Los clientes no deben ser forzados a depender de interfaces que no utilizan.
• D - Dependency inversion principle - Los sistemas deberian depender de abstracciones, no de implementaciones especificas.

Mis comentarios, la verdad el aporte de Robert C. Martin en la sintesis de estos principios orientan bastante a los desarrolladores a seguir buenas practicas de diseño. Muchas veces en algunos proyectos que me toco ayudar me encuentro con clases que son pequeños pulpos que hacen muchas cosas y al final el nombre no va para nada con el objetivo de la clase.

Creo que el segundo principio O (open/closed) cae bien sobretodo cuando hablamos de usar librerias y poder extenderlas. Tambien para clases que son claves en tus sistema.

El tercer principio del acronimo "L", me hace mas recordar el uso del diseño con polimorfismo.

El cuarto principio que hace referencia a la letra "I" (interface segregation principle) pues creeria que es aveces dificil de seguir, muchas veces me tope con clases que necesitan implementar interfaces aveces innecesarias, para gozar en parte de alguna funcionalidad y/o por encajar durante algun proceso que involucra el manejo de objetos de un mismo padre y/o que implementan X o Y interfaz (como el polimorfismo). Se ve dificil, pero no imposible de seguir.

La ultima letra del acronimo, la "D" es ya en nuestros días (sobre todo para los Ingenieros que trabajan con frameworks JAVA orientados a la WEB) creo yo de los mas importante y revolucionarios principios de la ingenieria, a permitido que realmente las aplicaciones empresariales sean robustas, simplemente por basar sus dependencias en Interfaces y no en implementaciones concretas.

Referencias: https://en.wikipedia.org/wiki/SOLID

¿Como realizar tuneo de un servidor postgresql?

 Para realizar el tuning de un servidor PostgreSQL, se pueden seguir los siguientes pasos:

1. Identificar el hardware y el sistema operativo: Es importante conocer las características del hardware y el sistema operativo en el que se encuentra el servidor PostgreSQL, ya que esto influirá en la configuración del servidor.
2. Analizar el uso de recursos: Es importante conocer cuántos recursos utiliza PostgreSQL en el servidor, tales como CPU, memoria y disco. Se pueden utilizar herramientas como el comando top en Linux o el Administrador de tareas en Windows para obtener esta información.
3. Configurar los parámetros de PostgreSQL: Los parámetros de configuración de PostgreSQL pueden ser modificados en el archivo postgresql.conf. Es importante tener en cuenta que los cambios realizados en este archivo sólo tendrán efecto después de reiniciar el servidor.

Algunos parámetros que se pueden modificar para mejorar el rendimiento del servidor son:

• shared_buffers: Este parámetro indica la cantidad de memoria que PostgreSQL utilizará para almacenar los datos en caché. Se recomienda que este valor sea de al menos el 25% de la memoria RAM del servidor.
• work_mem: Este parámetro indica la cantidad de memoria que PostgreSQL utilizará para ordenar y realizar operaciones de hash. Se recomienda que este valor sea de al menos el 1% de la memoria RAM del servidor.
• effective_cache_size: Este parámetro indica la cantidad de memoria que PostgreSQL utilizará para almacenar en caché el resultado de las consultas. Se recomienda que este valor sea de al menos el 50% de la memoria RAM del servidor.
• max_connections: Este parámetro indica el número máximo de conexiones que PostgreSQL permitirá al mismo tiempo. Se recomienda que este valor sea ajustado en función de la cantidad de usuarios que utilizarán el servidor.

Monitorizar el rendimiento: Una vez realizados los cambios de configuración, es importante monitorizar el rendimiento del servidor para comprobar si se han obtenido mejoras en el rendimiento. Se pueden utilizar herramientas como pg_top o pg_stat_activity para obtener información sobre el rendimiento de PostgreSQL.

Es importante recordar que el tuning de un servidor PostgreSQL es un proceso iterativo y que los cambios realizados pueden tener un impacto diferente en función de la carga de trabajo del servidor. Por lo tanto, es recomendable monitorizar regularmente el rendimiento del servidor y ajustar la configuración en consecuencia.