Este autor, en su afán por facilitar dentro de lo posible el desarrollo de software para todo tipo, se ha introducido en las entrañas de lo que es el software de empresa típico y ha definido elementos, objetos, patrones y ayudas específicas que facilitan el análisis, diseño y programación en general de aplicaciones de este tipo. El libro es Analysis Patterns.

La obra nos introduce en el mundo de los patrones, los conceptos y modelos de los negocios e intenta dar una visión general del porqué estos patrones pueden ayudarnos a simplificar la creación de aplicaciones. A través de los capítulos, se van viendo, tema por tema, todos los aspectos que en toda empresa se suelen abordar: contabilidad, plannings, inventario, etc.

Como suele decir Richard Stallman: “para leer buen código hay que leer buen código“; y esta obra la considero un buen sistema de análisis para el que se quiera aventurar a realizar análisis de sistemas de información.

Entradas relacionadas:

1. Paradigmas y Patrones

La práctica se basaba en realizar un sistema para resolver tableros de shikaku, mediante el algoritmo de vuelta atrás. Mi solución es óptima pero no del todo correcta desde un punto de vista académico, ya que el uso del algoritmo (de backtracking) es menos usado de lo que debería.

Para poder ver el código, este puede descargarse a través de un cliente de Subversion, en sistemas Unix/Linux es tan fácil como:

svn co http://project.bosqueviejo.net/svn/shikaku/trunk

Explicación del código

Bueno, tengo que reconocer que, después de algo más de un año de haberlo hecho, he tenido que releer y revisar de nuevo todo para acordarme (y reaprender) cómo hace lo que hace.

Por ello, voy a escribir una documentación básica sobre el código en sí, para tenerla como referencia, cuando tenga que volver al mismo otra vez, y para que sirva a todos aquellos que lo necesiten.

En principio, el código se divide en las siguientes clases:

• shikaku.tablero.Combinacion: esta clase se encarga de almacenar combinaciones. Una combinación es un rectángulo que se sitúa ocupando un espacio de X*Y=N. La combinación debe de tener en alguna de sus casillas el número contenido, por lo que se almacena también la ordenada de N para comprobaciones.
• shikaku.tablero.Ordenada: es cada uno de los números que aparecen en el tablero. Se almacena su posición dentro del tablero y la representación numérica del mismo.
• shikaku.tablero.Tablero: almacena las dimensiones del tablero, la lista de combinaciones fijas (las que solo tienen una combinación válida detectada) y la lista de soluciones posibles para el tablero.

Una ejecución de shikaku tiene los siguientes pasos:

1. Entra en main de la clase shikaku, donde se detecta el origen de datos, hasta saber de donde se va a cargar el tablero.
2. En run se crea una instancia del tablero, y se ejecuta, para cada punto del tablero, el generador de la clase Combinacion.
3. El generador se encarga de buscar combinaciones válidas para el punto dado, dentro del tablero y validando su posición dentro del tablero (es decir, que no haya parte del rectángulo fuera) y con respecto al resto de puntos (que no tenga contenido nada más que el punto del que tiene que hacer la combinación).
4. El último paso para la resolución, es llamando a buscaSoluciones, de la clase Tablero, que se encarga de realizar el algoritmo de vuelta atrás para buscar las soluciones al tablero.

Estos son los pasos más importantes dentro del código para resolver el tablero de shikaku.

La depuración

Uno de los motivos por los que el algoritmo no es del todo de tipo vuelta atrás, es precisamente por el uso de tres algoritmos voraces que se ejecutan antes que el último, de vuelta atrás. Estos algoritmos realizan una criba sobre las combinaciones basándose en tres premisas que debe cumplir cada combinación para ser válida:

1. Que no haya nada fuera del tablero: esto se realiza mediante una simple validación a la hora de generar las combinaciones. Es simple y rápida, y quita mucho procesamiento al algoritmo final.
2. Combinaciones con un solo número: esto se refiere a que dentro del rectángulo que conforma la combinación, solo esté contenido el número objeto de la combinación y ningún otro. Esta validación también está incluida a la hora de generar las combinaciones, para lo que se necesita, en el generador, pasar todos los puntos del tablero.
3. Eliminar combinaciones imposibles: imposibles, además de las que se descartan en los puntos anteriores, son las que colisionan con todas y cada una de las combinaciones posibles de otro número vecino. Si la combinación de un número colisiona con todas las combinaciones posibles de otro número, como es lógico, no podrá ser posible.

Ciertamente, con estos algoritmos se llega a resolver un alto porcentaje de los tableros básicos, sin necesidad de realizar el algoritmo de vuelta atrás. Solo los tableros grandes y con dificultad alta, necesitan, además de estos algoritmos voraces, el de vuelta atrás.

Mejoras

En sentido académico, teniendo en cuenta uno de los requisitos que se pide, que es que sea un algoritmo de vuelta atrás, quizás sea más correcto que la depuradora actúe solo a nivel de rama y no en profundidad.

Hay que tener en cuenta que esto penalizaría el rendimiento y empeoraría en lo que a gestión de memoria se refiere, pero prima más cumplir con los requisitos

Entradas relacionadas:

1. Algoritmos heurísticos y algoritmos voraces

¿Por qué una introducción acerca de closure?, pues porque uno de los lenguajes que comienza a ser muy usado, es precisamente este: clojure.

¿Qué es clojure?

Es un lenguaje concurrente, en definición corta, según su web oficial, es un lenguaje de propósito general, que se compila y ejecuta sobre la JVM, dando la versatilidad de un lenguaje scripting, pero al mismo tiempo la robustez que requieren los programas multihilo.

Además, permite el acceso a frameworks Java, con lo que su integración con los entornos Java hace que sea un lenguaje que compita directamente con Scala, en este campo.

Para los que programan en Java, PHP, Perl, Python, Ruby… ver lenguajes como Haskell, Erlang, Lisp, Prolog o Clojure puede resultar en principio algo chocante, ya que la sintaxis es muy diferente. Es normal, su forma de actuación, lo que se puede hacer con ellos y no con los otros, es también distinto. El cambio de sintaxis, fuera de ser un impedimento, yo lo considero una forma de obligarte a cambiar el chip, antes de comenzar a programar.

¿Y para qué sirve?

Bueno, tanto hablar, tanto hablar… pero, ¿y qué hace este lenguaje?, ¿para qué es bueno? En un primer vistazo, los desarrolladores del mismo te pueden responder de forma rápida: para concurrencia.

Después, más detenidamente, te puedes dar cuenta de que es un tipo lenguaje tipo Lisp, con lo que, no solo es bueno con la concurrencia, sino también con la organización de datos e identificación de forma inteligente… o lo que se suele llamar la inteligencia artificial.

Conclusiones

Lisp es un lenguaje que tengo en la lista de tareas por aprender. A través de clojure, ahora, puedo darle una visión un poco más enfocada a los entornos que se usan actualmente para la programación, de modo que pueda ser más útil que simplemente aprender Lisp.

Por mi parte, recomiendo la elección de este lenguaje a todo aquél que tenga problemas a resolver en entornos que requieran de un procesamiento deductivo y con alta concurrencia, por ejemplo: videojuegos, elementos de telecomunicaciones, etc.

No hay entradas relacionadas.

Dentro del tema de la calidad, visto como un amplio abanico de elementos que la conforman, nos topamos con uno bastante confuso y complejo al principio: la calidad interna.

¿Qué es la calidad interna?

Cuando se desarrolla un software, se desarrolla con una calidad medida según sus requisitos que pueden determinar su alto grado de calidad, midiendo una serie de parámetros. Pero estos parámetros no reflejan ni tienen en cuenta la calidad del proceso de creación del software en sí, ni la calidad del software escrito, solo la calidad externa, es decir, la función que realiza el software.

La calidad interna, sin embargo, mide y tiene presente la forma en la que se ha desarrollado el código de modo que pueda mantenerse (corregirse, ampliarse y adaptarse) de forma rápida y sencilla, gracias a un diseño e implementación limpia, simple y clara.

La importancia que tiene este tipo de calidad se muestra de manifiesto en varios textos como Scrum y XP desde las trincheras (de Henrik Kniberg) y algunos blogs como el de José Manuel Beas, Joseba Enjuto, una entrada de Diego Gómez en la web Dos Ideas, o incluso en el propio estándar ISO/IEC 9126.

¿Por qué es tan importante?

Para un desarrollador, la calidad interna es tan o más importante que la calidad externa, puesto que si un software hace lo que debe, pero una de cada 1000 veces no funciona, puede deberse a un fallo interno difícil de detectar que, pueda incluso verse agravado por la mala calidad con la que se ha desarrollado (diseñado o implementado) el sistema en sí.

En base a tiempo, un software desarrollado con una calidad baja o nula, puede ser desarrollado en un tiempo muy pequeño, ya que no se tiene en consideración muchos aspectos necesarios y útiles, como por ejemplo, una buena orientación a objetos, modularización del código, reutilización, algoritmos excesivamente complejos u ofuscados, etc.

Cuando, por un fallo (mantenimiento correctivo) hay que volver al código para corregir un defecto, y se detecta un error de diseño, modificar un código mal oliente, es más complicado que corregir un defecto en un código que está mejor desarrollado en base a patrones y reglas básicas de análisis, diseño o codificación.

En otras palabras: un programa con calidad interna baja es un programa que generará deuda técnica.

No hay entradas relacionadas.

Hacer código de mala calidad a toda prisa, es como pedir un crédito: puede que obtengamos un beneficio a corto plazo pero si tenemos que seguir desarrollando ese código, tarde o temprano tendremos que pagar todo el tiempo que nos habíamos ahorrado y los intereses. Refactorizar código mal escrito es siempre más difícil que escribirlo bien desde el principio.

Creo que se ve claro que, programar rápido no significa hacerlo bien, en la mayoría de los casos, es raro hacerlo rápido y bien. Por otro lado, lo que puede haber funcionado (incluso de milagro) en una ocasión, si necesita mejoras o cambios, puede dejar de funcionar, teniendo que invertir mucho más tiempo del que habría costado hacerlo bien desde el principio.

¿Hacerlo bien significa gastar muchas más horas? No realmente. Si llevásemos un cómputo de las horas invertidas en hacer un proyecto de forma rápida, a priori, podría parecer que se han invertido pocas horas y el trabajo está hecho. El problema viene después, cuando toca corregir los errores de cualquier índole que no se han tenido en cuenta, o simplemente, por la rapidez, se han cometido.

Normalmente, las horas invertidas en mantenimiento, superan con creces las horas invertidas en un desarrollo basura. La comparación con el haberlo hecho bien, es que el tiempo de desarrollo planificado crece, pero el de mantenimiento es nulo o muy, muy pequeño. Por lo que, a la larga (o al medio plazo) compensa.

No hay entradas relacionadas.

En postgresql, por ejemplo, el sistema de lenguajes que se pueden usar e implementar para la creación de funciones: PL/pgSQL, PL/Tcl, PL/Python, PL/Perl, PL/PHP, PL/Java, PL/Ruby, …; todos ellos se pueden ver en la página de documentación de PostgreSQL.

Esto quiere decir que, en una llamada a una función SQL se puede emplear una función específica programada en cualquiera de estos lenguajes, así como el lanzamiento de un trigger, puede ser compuesto por una serie de llamadas a estos procedimientos.

No obstante, la gente suele tener bastante miedo a usar estos sistemas para lógica de negocio por varios motivos, pero principalmente porque el despliegue es complejo.

Sí, en ciertos SGBD, un despliegue y mantenimiento resulta algo complejo, el hecho de mantener unas versiones y saber exactamente qué hay en producción y qué no hay, así como el hecho de que un cambio pueda hacerse en cualquier momento y pueda desvirtuar lo que haya en el repositorio en sí.

No obstante, puede solventarse con el uso de sistemas como migrations de rails, o similares. Es decir, no cargar nada directamente desde una interfaz abierta o desde la consola, sino desde una herramienta que permita controlar las subidas en forma de versiones.

En sí, el sistema de CHECK de PostgreSQL permite y da ventajas al usuario de desarrollar parte de la lógica de negocio. Allá donde no llegan los mecanismos típicos, es donde se puede comenzar a tirar de las funciones desarrolladas en cualquier lenguaje, con la potencia de que estas pueden ser lanzadas como CONSTRAINT, TRIGGERS o de forma inmediata en una consulta SQL.

En mi opinión, el uso de PostgreSQL como capa de datos, y además como capa de negocio, es una opción tan válida como extraer esa lógica a otros sistemas externos. La única nota negativa, es la interconexión, que obliga a que se haga con el conector de base de datos mientras que desarrollando la capa de negocio en otro tipo de framework, este acceso podría bien ser por mecanismos más orientados a RPC como SOAP o REST.

Entradas relacionadas:

1. Base de Datos Relacionales: SQLite, MySQL y PostgreSQL
2. CouchDB: REST y Base de datos documental
3. Inteligencia de Negocio

El caso es que muchos manuales y documentos me ayudaron a comprender los sistemas, su funcionamiento, estructura y elementos que se pueden encontrar en cada uno de los esquemas, o infraestructuras, que se pueden crear con ellos. Sin esta información hubiese sido difícil aprender tan rápidamente todo lo que concierne al mundo de la VoIP y sobre todo al mundo de SIP, uno de los protocolos que más y mejor permiten la convergencia entre los sistemas de telefonía y los sistemas informáticos.

El libro que recomiendo es un documento que he leído varias veces y que me ha ayudado como guía en mi trabajo, sobre todo para entender ciertos problemas que se sucedían en los entornos de pruebas y en incidencias ya en producción.

Comienza con una explicación sobre la historia del propio protocolo, cómo surgió. Es interesante saber la historia de la tecnología que usamos, porque así comprendemos sus ventajas e inconvenientes, sus fortalezas y sus carencias.

Es pequeño (no tiene más allá de 264 páginas) pero con mucho contenido muy condensado y repleto de material gráfico que ayuda mucho más a comprender lo que explica el libro en sí.

Recomiendo su lectura a todos aquellos que necesiten trabajar en entornos VoIP con interconexiones SIP.

No hay entradas relacionadas.

Leyendo el blog de dos ideas con referencia a un artículo que publicaron llamado NoSQL: el movimiento en contra de las bases de datos, se comenta una conferencia en la que grandes profesionales del sector de los sistemas, con necesidades de escalabilidad y alta capacidad de almacenaje, mencionaban sus soluciones NoSQL.

Entre ellos, representantes de empresas como Google, Amazon, Facebook, Twitter, LinkedIn, … pusieron en conocimiento de todos los asistentes sus soluciones ya desarrolladas y en funcionamiento para suplir las carencias que las bases de datos tradicionales no podían cubrir.

Las ventajas de NoSQL

Las ventajas de estos sistemas de almacenamiento (hay muchos integrantes de este movimiento que consideran una aberración llamarlos bases de datos) son las siguientes:

• Pueden manejar enormes cantidades de datos: esto es debido a su propia estructura distribuida. Por ejemplo, HyperTable, una implementación de código abierto basada en BigTable (de Google), puede escribir 1000 millones de celdas de datos por día. Al igual que BigTable, con MapReduce, es capaz de manejar 20 petabytes diarios.
• Se ejecutan en clusters de máquinas baratas: estos sistemas no requieren de apenas computación, en comparación con los sitemas gestores de base de datos tradicionales y basados en SQL, por lo que se pueden montar en máquinas de un coste más reducido y en mayor número, gracias a su nivel de escalabilidad.
• No generan cuellos de botella: el problema de fondo de los sistemas SQL, es que deben de transcribir cada sentencia para poder ser ejecutada y, cada sentencia compleja requiere, además de un nivel de ejecución más concreto para poderse llevar a cabo, por lo que constituye un punto de entrada común, único y conflictivo en base a rendimiento.
• Solo lo estrictamente necesario: son sistemas simples que no tienen un sistema de consulta complejo ni con capacidad declarativa para en una sola línea realizar una cantidad interna de operaciones desorbitada.

Las desventajas

Bueno, y después de poner estos sistemas por las nubes… ahora toca pegar un poco los pies al suelo y darse de cara con la realidad. Quiero decir que, sí, hay desventajas, esto no es una panacea que sirva para paliar la necesidad del almacenaje de datos para todos los casos. En entornos de sistemas de información, en gestión de cuentas, y entornos en los que es preferible que los datos puedan tener algo más de inteligencia, en lugar de algo más de rapidez, estos sistemas no son aconsejables, ya que la única, pero mayor desventaja de estos es que no respetan ACID.

Conclusiones

En mi caso particular, trabajando en un área de sistemas relacionado con la telefonía en el que premia más la velocidad de tratamiento de datos, así como la capacidad para poder manejar gran cantidad de los mismos, y en el que la integridad referencial es algo que ni se usa ni se tiene en cuenta, sí, es una solución real, una forma de ahorrarse gran cantidad de código y dolores de cabeza con respecto a la escalabilidad y concurrencia de la información dentro de la plataforma tecnológica.

Ahora, si mi trabajo fuese desarrollar sistemas CRM, ERP o similares, que dependen más de la integridad de los datos, así como su relación y unas reglas de negocio establecidas y programadas, es innegable que las bases de datos con soporte SQL agregan mucho valor en este sentido.

Por lo que, podemos concluir en que, para programación de sistemas son un recurso muy útil y que puede facilitar y paliar problemáticas relacionadas con el almacenaje de información, así como el tratamiento in-situ de la misma con cara a la lógica del servicio, y por otro lado, si lo que premia más es tener una lógica de negocio bien definida, en ese caso, quizás es mejor seguir usando los sistemas SQL.

Entradas relacionadas:

1. Base de Datos Relacionales: SQLite, MySQL y PostgreSQL
2. CouchDB: REST y Base de datos documental
3. Lógica de negocio en la base de datos

Tener este tipo de URLs, o URIs en nuestro dominio, se puede hacer mediante la creación de directorios y especificando los ficheros dentro de los mismos que tengan los nombres (sin extensión) que queremos que se visualicen en la barra del navegador… pero no es nada útil y es complejo, sobre todo cuando se usan entornos como WordPress o similares, donde el contenido de la base de datos dicta lo que aparece en la página, y es totalmente dinámico.

La solución que se puede emplear: rewrite. En Apache, a través del módulo mod_rewrite, se pueden crear reglas de redireccionado de modo que una URL que es:

http://midominio.com/?p=129&a=crea-usuario

Se puede convertir en:

http://midominio.com/crea-usuario/129

En el caso concreto, tan solo bastaría con agregar un bloque de configuración como el siguiente:

RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^/(.+)/([0-9]+)$    /index.php?p=$2&a=$1

Para más información vea la documentación oficial de Apache.

No hay entradas relacionadas.

En todas las empresas en las que he trabajado, siempre surge el problema de que, cuando sale algo nuevo o se crea un cierto programa, un sistema o una forma de trabajo, si la persona que la ha motivado no sabe su nombre: se la inventa.

Esto pasa con mucha frecuencia, y no es malo, pero es común que toda la empresa termine usando el vocablo en muy poco tiempo y, toda persona que entre nueva, si ese vocablo le parece desconocido o le sugiere otra cosa distinta, le lleve a confusión hasta que se lo expliquen.

Para esto se suelen hacer glosarios o lo que, en ingeniería del software se conoce como: Modelo de Dominio.

Este documento tiene varias partes, una de ellas se especifica como un glosario, estando ordenado alfabéticamente, y recogiendo todas las palabras que se usan, comúnmente en el entorno profesional en el que se mueve la empresa, y las palabras referentes a productos y servicios específicos que se comercializan o adquieren por parte de la empresa. Otra de las partes es la relación que hay entre conceptos que se manejan en la empresa, definición de características de cada uno de los elementos y restricciones de uso de los mismos.

Ceñirse a estándares es una forma de no necesitar un modelo de dominio, pero es complicado no saltarse las normas alguna que otra vez, por lo que, aún tomando precauciones de llamar a todo por su nombre, es conveniente y productivo, sobre todo para las nuevas incorporaciones o subcontratas, tener este documento disponible.

No hay entradas relacionadas.