miércoles, 17 de septiembre de 2014

WP - Consejos de programación 1 - Don’t be WET, stay DRY

En esta ocasión quiero iniciar una serie de consejos de programación que considero importantes a nivel de eficiencia, orden y -por que no decirlo – estética. Estos consejos se basan en algunas prácticas que he observado durante los pocos años de mi carrera. Algunas de esas prácticas son buenas, mientras que otras son las que quisiera evitar. También se basan en cosas interesantes que he encontrado en uno que otro artículo por el Internet (de esos artículos donde la gente gustan hablar de temas con acrónimos de 3 o 4 letras).

Iniciaré la serie compartiendo algo acerca del principio de desarrollo de software conocido como DRY (inglés: seco), que significa Don’t Repeat Yourself. Creo que ya saben más o menos por donde va la cosa, pero antes de definir el término, haré una pequeña introducción.

Introducción

Algo que he visto muchas veces es que cuando se quieren añadir nuevos elementos a una aplicación (ventanas, controles de usuario, funciones), y estos son muy similares a elementos ya existentes, lo que hacen los programadores es copiar y pegar el código fuente correspondiente a dichos elementos, y hacer las modificaciones en la copia de acuerdo a los nuevos requerimientos. Esta técnica es vulgarmente conocida en nuestro medio como “copy-paste”, y también es aplicable a la técnica que usan los estudiantes cuando buscan sus tareas en Wikipedia, El Rincón del Vago, Taringa, o Yahoo respuestas, en el peor de los casos (aceptémoslo, todos hemos aplicado esta técnica alguna vez, jejeje…)

Considero que esta una práctica muy arraigada debido a que esto se considera la forma más rápida de incluir nuevos elementos en una aplicación. Pero si se analiza cuidadosamente, al final no resulta ser la forma más rápida, porque:
  • Al crear un nuevo elemento a partir de la copia de uno ya existente, implica que es necesario cambiar parte del código fuente, para cambiar o añadir la funcionalidad deseada. También hay que tener particular cuidado con aquellos parámetros que han sido “quemados” (hard-coded) dentro de la aplicación.
  • El resultado es una aplicación con una gran cantidad de código fuente, lo que también deriva en la existencia de varios archivos desorganizados y desperdigados en la carpeta que contiene el proyecto.
  • Si se requiere cambiar una funcionalidad principal que se ha repetido en todos los elementos copiados, esta modificación debe hacerse en cada uno de ellos.

Definición de DRY y WET

Basta de hacer catarsis, procederé a definir los conceptos más formalmente. En la “ingeniería de software”, el término DRY, o “Don’t Repeat Yourself”, se refiere a reducir la repetición de información de cualquier tipo. El principio DRY dicta: “Cada pieza de conocimiento debe tener una representación única, no ambigua y autoritaria dentro de un sistema”. El término fue acuñado por Andy Hunt y Dave Thomas en su libro “The Pragmatic Programmer”. Eric Raymond hace referencia a un término equivalente, llamado SPOT (“Single Point Of Truth”) en su libro “The Art Of Unix Programming”. Cabe destacar que el término no se limita a código fuente ni datos, sino a un sistema cualquiera. Tampoco se refiere necesariamente a no repetir código fuente en un sistema informático, sino que este tenga una fuente única dentro del sistema.

El término contrario a este es WET (inglés: mojado), al cual se le han dado muchos significados: “We Enjoy Typing”, “Write Everything Twice”, “We Edit Terribly”, etc. Obviamente, significa que existen “piezas de conocimiento” con múltiples representaciones, que podría traducirse como tener la misma información repetida varias veces.

Ventajas de DRY

Ustedes se preguntarán por qué tomarse la molestia de aplicar este principio, si han vivido felizmente con la técnica de copy-paste por mucho tiempo, a tal punto que ya tienen práctica con la mano izquierda para hacer las secuencias de teclas Ctrl+C y Ctrl+V. Pues bueno, las ventajas que yo he observado de primera mano en las aplicaciones que he visto son las siguientes:
  • Toda elemento (función, método, procedimiento, clase) e información dentro de la aplicación posee un origen único, por lo que si se requiere modificar la funcionalidad principal de alguno de ellos, debe hacerse en un solo punto.
  • La cantidad de código fuente se reduce.
  • El desglose de funcionalidades permite el manejo de múltiples capas. Esto también permite una organización más clara de los archivos de código fuente.
  • El trabajo de añadir nuevos elementos basados en elementos anteriores se reduce, ya que no implicará copiar y modificar código fuente para satisfacer los nuevos requerimientos, sino más bien reutilizar elementos y funcionalidades ya existentes. En el mejor de los casos, solo será necesario invocar los elementos ya existentes, con parámetros distintos, para obtener los resultados requeridos.

Desventajas de DRY

A pesar de todo, y como todo en esta vida, DRY posee algunas desventajas que hay que tener en cuenta:
  • Muchas veces se requerirá de análisis profundo para encontrar una forma aceptable de centralizar todos los elementos de un sistema. La construcción de este kernel para la aplicación puede tomar algo de tiempo.
  • En algunos casos, la solución centralizada será menos eficiente en tiempo de ejecución que la solución repetitiva. Un buen ejemplo de ello es cuando una consulta muy utilizada en una base de datos relacional (digamos de SQL Server) se coloca en una función de usuario para poderla usar varias veces. La función por si sola puede ser eficiente, pero al intentar utilizarla dentro de otras consultas, puede ser más lento y pesado que si la consulta no hiciera uso de ella.
  • Dejar de lado el hábito de copy-paste, jejeje…

Cómo implementar el principio DRY

Dicho lo anterior, ahora os describiré algunas técnicas que os pueden ayudar a implementar el concepto de DRY en vuestros programillas:
  • Refinamiento del sistema en partes individuales con funcionalidades específicas y diferenciadas (técnicas top-down y bottom-up). Como me decían en la materia Programación Estructurada, “hay que reducir el problema en problemas más pequeños” (o algo así).
  • Agrupar elementos y funcionalidades similares, a  nivel de archivos y directorios, así como a nivel de código fuente.
  • Si se observa que una funcionalidad o elemento se repite más de una vez, o bien que es son muy parecidos a otra funcionalidad o elemento existente, entonces centralizarlos en un solo lugar. Por ejemplo, en la programación orientada a objetos, si se tienen por ejemplo las clases Profesor y Estudiante con propiedades y métodos similares, lo mejor sería que los elementos comunes los heredaran de una clase padre (Persona, por ejemplo).
  • En el caso de programación orientada a objectos, hacer uso de la herencia, clases abstractas, interfaces, y otros elementos que nos permiten centralizar la funcionalidad e información en clases, y hacer uso extensivo de ellas.
  • Hacer uso de Frameworks, los cuáles brindan funcionalidades comunes a toda aplicación. También incluyen generadores de código fuente, que construyen automáticamente elementos de uso común en base a características específicas. Ejemplo de ello es el Generador de Formularios del Framework para PHP llamado Symfony, que genera formularios web a partir de la definición del modelo de una base de datos.

¿Generadores de código fuente?

En este momento podría surgir la duda de por qué usar un generador de código fuente, si estos podrían generar código repetitivo. Si bien esto es cierto, no se salen del principio de DRY, ya que en realidad el código fuente generado automáticamente ha sido construido a partir de un mismo origen: el generador de código fuente. Esto implica que si se hace uso del mismo generador, este construirá el mismo código fuente en cualquier momento si se proporcionan las mismas condiciones para su generación.

Observaciones finales

El principio DRY nos presenta facilidades y ventajas con respecto a WET, ya que a la larga pueden facilitarnos el trabajo al reducir el tiempo de programación reutilizando elementos y funcionalidades ya existentes. Sin embargo, el llevar un sistema a una estructura DRY puede llevar tiempo de análisis, y muchas veces no será perfecto. Pero a pesar de esta desventaja, considero que vale la pena hacer el intento, ya que a la larga nos facilitará el trabajo a nosotros mismos quienes desarrollamos una aplicación, así como a los colegas que se encargarán de extender nuestro sistema informático en un futuro.

Los invito a escribir sus comentarios y opiniones acerca de este tema.



Publicado originalmente el 16/08/2012, en http://itsouvenirs.wordpress.com/2012/08/16/consejos-de-programacion-1-dont-be-wet-stay-dry/.

WP - Cinnamon 1.3.1 en Fedora 16

En esta ocasión mostraré como instalar Cinnamon en Fedora 16, que es una variante de escritorio desarrollada originalmente para Linux Mint, y basada en Gnome 3 y Mutter como decorador de ventanas. Cabe mencionar que la versión Live de Fedora 16 viene con Gnome 3 como escritorio por defecto, el cual, en lo personal, me parece bastante creativo y un poco más eficiente que las primeras versiones de Unity de Ubuntu.

Para instalar Cinnamon, lo primero que debe hacerse es añadir el repositorio de éste para Fedora, en YUM. Puede hacerse desde la línea de comandos así:

$ su
# curl http://repos.fedorapeople.org/repos/leigh123linux/cinnamon/fedora-cinnamon.repo -o /etc/yum.repos.d/fedora-cinnamon.repo

Luego, para proceder a su instalación, ejecutamos:

# yum install cinnamon

Finalmente, solo basta cerrar nuestra sesión y volver a ingresar, eligiendo ahora a Cinnamon como escritorio. Para ello se da click en el botón sesión, y se selecciona el escritorio a utilizar.

Selección de escritorio Cinnamon durante el inicio de sesión.
Vista del escritorio Cinnamon en Fedora 16.


Publicado originalmente el 27/03/2012, en http://itsouvenirs.wordpress.com/2012/03/27/cinnamon-1-3-1-en-fedora-16/.

martes, 16 de septiembre de 2014

WP - Habilitar tarjeta Broadcom Wireless en Fedora 16

Luego de instalar Fedora 16 en mi computadora, una DELL Inspiron 1525, me encontré con el inconveniente de que la tarjeta de red inalámbrica no funcionaba, debido a que el sistema operativo no incluye ni provee controladores para esta tarjeta de red. Esto se debe a la filosofía de Fedora, de proporcionar solamente software libre, y hasta el momento los controladores que existen para esta tarjeta de red son propietarios.

Sin embargo, existe una alternativa: paquetes kmod o akmod, que son módulos de kernel para controladores. Éstos pueden obtenerse vía internet (conectando la computadora con un cable de red, claro está), desde el repositorio RPMFUSION. La otra opción es descargar los paquetes desde el sitio web http://mirror.liberty.edu/pub/rpmfusion/nonfree/fedora/releases/16/Everything/x86_64/os/

Si se decide utilizar el repositorio RPMFUSION vía Internet, es necesario incluir el repositorio correspondiente en YUM, así:

$ su
# yum localinstall --nogpgcheck http://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-stable.noarch.rpm http://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-stable.noarch.rpm
# yum update

Luego de ello, tenemos la opción de usar paquetes kmod o akmod. Los kmod son paquetes precompilados que sirven como interfaz entre el kernel y los controladores, propios de una versión de kernel específica. Los akmod son paquetes que compilan kmod "al vuelo", al momento de iniciar el sistema operativo, de acuerdo al kernel que se esté utilizando.

Si se desean usar kmod, primeramente debemos obtener la lista de módulos disponibles, de acuerdo a la versión del kernel que se posea:

# yum list kmod-wl-\*

Los módulos poseen en medio de su nombre la versión del kernel a la que corresponden. Si por ejemplo se desea el kmod para el kernel 3.2.9, entonces se debe proceder a instalar el paquete kmod-wl-3.2.9-1.fc16.i686.i686, así:

# yum install kmod-wl-3.2.9-1.fc16.i686.i686

Si, por otra parte, se desea instalar un akmod, procedemos a instalar la versión más reciente, de la siguiente forma:

# yum install akmod-wl

Finalmente (independientemente de si elegió usar kmod o akmod), procedemos a instalar el controlador correspondiente a la tarjeta de red, en su versión más reciente:

# yum install broadcom-wl

Luego reiniciamos la computadora, para que el módulo respectivo sea cargado en el kernel en ejecución, luego de lo cual ya debería funcionar adecuadamente nuestra tarjeta de red Broadcom, detectando las redes disponibles en la zona.

Instalación sin conexión a Internet

El título no es del todo cierto, ya que es necesario descargar los paquetes correspondientes desde el sitio web http://mirror.liberty.edu/pub/rpmfusion/nonfree/fedora/releases/16/Everything/x86_64/os/ Debe buscarse y descargarse el paquete kmod-wl en la versión correspondiente al kernel que se utiliza, o la versión akmod-wl más reciente, según la alternativa. También es necesario descargar la versión más reciente o más apropiada del controlador broadcom-wl. Luego, se proceden a instalar los paquetes con permisos de administrador, y se reinicia la computadora, para activarlos, y poder hacer uso de la tarjeta de red inalámbrica.

Referencias


Enlaces de interés


Publicado originalmente el 10/03/2012, en http://itsouvenirs.wordpress.com/2012/03/10/habilitar-tarjeta-broadcom-en-fedora-16/.

viernes, 12 de septiembre de 2014

Cambiar tiempo de espera para ejecución de comandos en NHibernate vía código

Las consultas ejecutadas con NHibernate tienen un tiempo de espera predeterminado de 30 segundos. Sin embargo puede que este tiempo no sea suficiente para ejecutar algunos comandos o consultas complejas.

Para cambiar el tiempo de espera a nivel global a través de la configuración NHibernate vía código, se puede establecer el valor de la propiedad command_timeout al momento de configurar la fábrica de sesiones, de la siguiente manera:

NHibernate.Cfg.Configuration configuracion;

// Inicialización de configuración de NHibernate
// ...

// Estableciendo nuevo tiempo de espera (como cadena, en segundos)
configuracion.SetProperty(NHibernate.Cfg.Environment.CommandTimeout, "150");

// Creando fábrica de sesiones
ISessionFactory fabricaSesiones = configuracion.BuildSessionFactory();

Con esto se configura la fábrica de sesiones para que cada vez que ejecute comandos sobre la base de datos utilice el tiempo de espera especificado. El tiempo de espera se indica en segundos, ya que de acuerdo a la documentación es el que se asigna por defecto a los IDbCommand generados por NHibernate para las operaciones en la base de datos, y el tiempo de espera para estos se especifica en segundos.

De momento solo lo he probado en NHibernate 3, específicamente la versión 3.3.1.4000, por lo que no estoy seguro si existe en versiones previas, aunque es muy probable.

miércoles, 8 de mayo de 2013

WP - KMOD y AKMOD

Un kmod, o Kernel Drive Module (Módulo de Kernel para Controlador) es una interfaz pre-compilada de software de bajo nivel, que sirve como interfaz entre el kernel y un driver. Éstos módulos son cargados automáticamente por demanda en la memoria RAM, siendo incluidos en el Kernel en ejecución. La desventaja de los kmod es que son propios de un kernel específico, por lo que no funcionarán en ningún otro kernel. Esto es un grave inconveniente, ya que se pierde su funcionalidad al actualizar el kernel del sistema operativo, y se hace necesario recompilar el módulo para el nuevo kernel, o bien obtener el compilado correspondiente.

Los akmod representan una solución a este problema de dependencia, ya que al iniciar el sistema operativo, éstos revisan si falta algún kmod compatible con el kernel en ejecución, y si es así, recompilan el kmod para dicho kernel. La dessventaja de éstos (relativamente baja diría yo en comparación con la ventaja que ofrece) es que presentan mayor sobrecarga que los paquetes kmod normales, debido a que requieren herramientas de desarrollo para poder compilar los módulos “al vuelo”. En el caso de Fedora, se requieren los paquetes kernel-devel propios del kernel a utilizar. También existe la posibilidad de que los módulos compilados automáticamente no sean totalmente compatibles con el kernel utilizado.

Referencias

 Enlaces de interés


Publicado originalmente el 10/03/2012, en http://itsouvenirs.wordpress.com/2012/03/10/kmod-y-akmod/.

viernes, 19 de abril de 2013

WP - Desinstalar instancia de SQL Server u otros componentes

Para ingresar ventana de desinstalación de componentes de SQL Server debe ejecutarse el siguiente comando:

ARPWrapper.exe /Remove

Esta aplicación se encuentra ubicada en la carpeta Setup Bootstrap, ubicada en la carpeta de instalación de la instancia de SQL Server. Por ejemplo, en el caso de tratarse de SQL Server 2005, esta carpeta se encuentra por defecto en la siguiente ruta:

C:\Archivos de programa\Microsoft SQL Server\90\Setup Bootstrap

Me disculpo porque de momento no tengo instalado SQL Server correctamente en mi computadora, por lo que no puedo mostrarles con más detalle los pasos para desinstalar una instancia de SQL Server, u otros componentes.

Publicado originalmente el 09/03/2012, en http://itsouvenirs.wordpress.com/2012/03/09/desinstalar-instancia-de-sql-server-u-otros-componentes/.

WP - Tutorial de Symfony 2 - 1. ¿Qué es Symfony?

Creo que la mejor forma de iniciar el tutorial es a partir de la pregunta: ¿qué es Symfony? Bueno, yendo al grano, Symfony es un Famework de desarrollo web para PHP. Creo que esta definición no es suficiente ¿verdad?. Entonces, adéntremonos un poco más en el concepto, historia y personalidad (por así decirlo) de Symfony, partiendo desde el concepto básico de framework.

1. Framework de desarrollo

La primera pregunta que viene a nuestra mente es: ¿qué es un framework?. Un framework (Marco de trabajo, en español), dentro del ámbito de la computación, es una metodología, es decir, un conjunto de pautas a seguir para el desarrollo de una aplicación. Estas pautas también se extienden a la estructura y funcionamiento interno de una aplicación, ya que incluyen patrones que deteminan su arquitectura. Sin embargo, un framework no se queda solamente en un concepto abstracto, sino que también provee un conjunto de componentes de software prefabricados de fácil integración, que permiten poner en práctica dichos patrones, y permiten dar forma a la aplicación de una manera más sencilla.

2. Framework de desarrollo web PHP

El concepto de framework es extenso y aplicable a múltiples áreas de la computación, por lo que hay que delimitarlo a nuestro caso en particular. Symfony es un framework orientado específicamente al desarrollo web, es decir, a la construcción de sitios web robustos con contenido generado dinámicamente. Adicionalmente, Symfony es un framework creado especialmente para ser utilizado con el lenguaje de programación PHP, que es un lenguaje de programación interpretado del lado del servidor, y permite generar el contenido que se muestra en las páginas web de forma dinámica. Y no solamente eso, sino que Symfony en sí mismo ha sido desarrollado propiamente en PHP.

3.Un poco de historia…

Symfony fue creado originalmente por Fabien Potencier, fundador y dueño de la compañía francesa de software Sensio Labs, con el objetivo de facilitar y hacer más rápido el desarrollo de sitios web dentro de su compañía, a través de la automatización de tareas comunes. Fabien se basó en los framework Mojavi y Ruby On Rails, para la creación del framework.

Logo de Symfony usado en las versiones 1.x
La creación de Symfony inició en el año 2003. La primera versión del framework fue lanzada en el año 2005, y se utilizó para la creación de un sitio de comercio electronico. Luego de ser utilizado en otros proyectos más, Symfony fue lanzado bajo la licencia MIT como software libre, con el objetivo de donarlo a la comunidad creciente de programadores web, y además aprovechar su retroalimentación para la corrección de defectos y el enriquecimiento del proyecto.

La primera edición de Symfony continuó siendo mejorada hasta llegar a la versión 1.4. Cabe mencionar que paara esta primera versión, miembros de la empresa Sensio Labs crearon  una documentación bastante práctuca y detallada, en la que se incluyen las muy conocidas guías prácticas Askeet y Jobeet. Posteriormente se inició la creación de una segunda versión del framework, que fue lanzada en el año 2011, y cuya última versión estable hasta la fecha es la que utilizaremos en el presente tutorial.

¿Por qué lo llamaron “Symfony” y no “CualquierNombreFramework”? Porque Fabien quería una nombre corto que tuviera una letra ‘s’ (de Sensio) y una letra ‘f’ (de framework), que fuera fácil de recordar y que no estuviera asociado a otra herramienta de desarrollo. Además, no le gustan las mayúsculas. “Symfony” era muy parecido a lo que estaba buscando, aunque no es una palabra correcta en el idioma inglés (la palabra correcta es “symphony”), y además estaba libre como nombre de proyecto. La otra alternativa era “baguette”. (Symfony 1.2, la guía definitiva)

Actualmente Symfony es utilizado, en sus distintas versiones, en una amplia gama de sitios web, como Yahoo! Bookmarks, Delicious, Dailymotion, Opensky, eRepublik, entre otros.

4. Symfony como filosofía y comunidad

Creo que ya se aclaró un poco más la definición de Symfony como framework, y además se conoció brevemente su historia. Pero en realidad Symfony es algo más que un framework, es también una filosofía y una comunidad. Es una filosofía porque es provisto bajo una licencia de código abierto, con el ideal de que otros desarrolladores lo personalicen y enriquezcan con su propia imaginación. Por otra parte, es una comunidad, ya que tras Symfony, existe un amplio conjunto de desarrolladores que hacen posible su existencia, no solo dentro de Sensio Labs, sino alrededor del mundo.

5. Referencias

6. Enlaces de interés

Publicado originalmente el 25/02/2012, en http://itsouvenirs.wordpress.com/2012/02/25/tutorial-de-symfony-2-1-que-es-symfony/.
Con la tecnología de Blogger.