Ir al contenido principal

La idea de nuestro propio “Framework”

Creo que muchos de los desarrolladores hemos tenido la idea e incluso iniciado el desarrollo alguna vez de nuestro propio “Framework” para generar aplicaciones. No veo malo el escribir otro Framework. Pero muchas veces solo terminan limitándose, haciendo lo fácil mas fácil y lo difícil casi imposible, poco flexibles. Se vuelven una carga que mantener. Algo con lo que los desarrolladores no están muy entusiasmados en trabajar, porque prefieren usar algo nuevo.
He notado que esos pequeños Frameworks tienen algunas características en común (esta no es una receta, solo son unos de los problemas comunes que he visto en esos pequeños frameworks privados):
No se conocen los frameworks existentes: Lo más seguro es que ya exista algo que hace lo que se quiere lograr. Puede que se trate de un problema resuelto. Quizás lo mejor sea contribuir a un proyecto open source existente, agregando las características que se necesitan. Si la idea es hacer lo mismo que ya hace otro Framework, debe haber una razón más fuerte que el solo no tomarse la molestia de aprender a trabajar con los existentes.
No tienen un proyecto real donde usarlo: Sin una aplicación real donde probar los conceptos es difícil que se le atine a lo que realmente se necesita en un proyecto real. Puede tomarse en cuenta la experiencia de proyectos anteriores. Aun así creo que uno de los riesgos que se corre al no tener un proyecto donde probarlo es agregar características que no se necesitan u omitir las necesarias.
No son de código abierto (Open Source): Varios de estos pequeños frameworks son para uso exclusivo de quien lo desarrollo y a veces no quieren mostrarle el código a nadie fuera de la empresa, como si alguien les fuera a robar la idea y teniendo el secreto ya nadie necesitaría (contrataría) del autor del framework. Cuando en realidad es todo lo contrario, Al liberar el código de la librería/framework ayuda a que el código tenga mas ojos; y mas ojos pueden ayudar a que el proyecto sea mejor. Además de que es una buena oportunidad de que el autor se de a conocer en la comunidad (publicidad) y que la comunidad se beneficie de esto, ambas partes ganan, pero sobre todo código.
No conocen la teoría: Conocer la teoría para que la practica tenga mas sentido. Cuando el proyecto tiene buenas bases teóricas logra ser mas consistente en la manera como esta desarrollado y tanto la mantenebilidad, como su extensibilidad generalmente logran ser mayor.
Quieren abarcar mucho: El no tener un objetivo claro o un problema concreto el cual se quiere resolver termina generando una gran cantidad de código que nadie quiere usar.
El desarrollo de un framework es una buena actividad para ser un mejor desarrollador, es algo que se debe intentar (más si es en un proyecto open source). La innovación puede ocurrir. Si conociendo las soluciones existentes se cree necesitar una opción mas, pues adelante.

Comentarios

Entradas más populares de este blog

Bloqueos

Una de las preguntas típicas de las juntas matutinas en los equipos de desarrollo de software es ¿Hay algún bloqueo? Si lo hay, se trata de ver qué es lo que está esperando esa persona y encontrar la forma de que se desbloquee; pero ¿Qué son los bloqueos? Los bloqueos son obstáculos que te impiden realizar o avanzar en tu trabajo. Evitan que puedas seguir progresando en el proyecto.

He notado que es común en las personas con menos experiencia decir que tienen un bloqueo cuando están batallando, debido a su poca experiencia, en la forma de resolver un problema. Han intentado varias formas y se empiezan a quedar sin ideas de como puede ser resuelto el problema o como pueden cumplir con el requerimiento especificado. Al quedarse sin opciones de qué intentar dicen que tienen un bloqueo con la tarea y que a menos que alguien les diga como resolverlo, no se puede avanzar en la tarea.

En personas con más experiencia, ese tipo de bloqueos no ocurren, una persona con experiencia ha visto pro…

Firebird 2.1 UPDATE OR INSERT

Another great feature that I like in Firebird 2.1 is the UPDATE OR INSERT statement. It's a really time saver and it makes the SQL cleaner.

For example suppose I have a products table like the one I use in my last post and an inventory table to store the product stock. Before Firebird 2.1 if I want to set the stock for a product I needed to check if a record for that product_id already exists; if the product_id already exists then I write an update. If not then I write an insert statement. So I ended up with something like this:


IF EXISTS(SELECT * FROM inventory WHERE product_id = :product_id ) THEN
UPDATE
inventory
SET
stock = :stock
WHERE
product_id = :product_id;
ELSE
INSERT INTO inventory
(product_id, stock)
VALUES
(:product_id, :stock);

In this example I only update one field but when I have to update a big table I ended up with a big chunk of code and thinking: "there should be another (better) way to do this".

Fortunately now with Firebird 2.1 there…

Database Mail en MS SQL Server 2005

Configuración de Database Mail en MS SQL Server 2005

Primero se debe de habilitar, ya que por omisión el componente esta deshabilitado, Utilizando el SSMS (SQL Server Management Studio)


Si no esta habilitado aparecerá un mensaje preguntado si lo habilita, después aparece esta ventana donde se pregunta al usuario que es lo desea hacer.


Seleccionamos la primera opción para crear un perfil.


Configuramos el perfil y le agregamos por lo menos una cuenta.


Seleccionamos el perfil como public y default.


Para mandar correo se utiliza el procedimiento msdb.sp_send_dbmail por lo tanto el usuario que intente mandar correo debe de tener permiso para la base de datos msdb.

Referencias:
http://www.sqlservercentral.com/columnists/cBunch/introtodatabasemailinsql2005.asp