lunes, 27 de julio de 2009

Métodos de Extensión en Visual Studio 2008

Alguna vez, cuando estaba programando, me preguntaba si las cosas en la POO se podían hacer algo mas 'elegantes' y sin tanto rollo.

Un ejemplo común en la escuela es el clásico... 'De un arreglo de números enteros, decir cuáles son pares', y es típico que tenemos que hacer una función que me diga si es par o no, y mandar a llamar en un ciclo que recorra número por número...

Y me cuestionaba si se podía hacer algo como:

int[10] arrayNumeros;
arrayNumeros[0] = 4;
...
arrayNumeros[9]=62;

int[] arrayPares = arrayNumeros.Pares();

Quería hacer lo que está en color azul, que mandara a llamar a una función Pares y me regresara todos los pares en la función 'Pares', sin que tuviera que llamarla así:

int[] arrayPares = Pares(arrayNumeros);

Lo primero que se me vino a la cabeza es utilizar la Herencia, pero imagínense heredar de una clase solo para poder implementar un método.

Pues bien, la respuesta es que sí se puede hacer sin herencia en Visual Studio 2008 (con cualquiera de los lenguajes .NET, como C# o VB.NET), y el nombre de esta característica es 'Métodos de Extensión'.

Los métodos de extensión, son, como su nombre lo indica, métodos que se agregan a los tipos existentes en el .NET Framework o cualquiera que nosotros hayamos creado con cualquier lenguaje .NET, SIN NECESIDAD de hacer uso de la herencia para poder 'añadirle' alguna función o procedimiento (estos métodos se manejan de manera especial, pero se invocan como si se tratase de un método propio del tipo al que extendemos).

Lo explicaré utilizando el lenguaje C# (para mejor similitud con el añejo C++)

Primero, se define una clase estática donde estarán todas los métodos 'agregados' o extendidos, sin anidar esta clase con alguna otra.

por ejemplo:

namespace PruebaPares{

public static class Extensiones{

}

}

Después, se define el método o función que 'extienda' al tipo de: 'arreglos de enteros' (en nuestro caso), para esto el método también tiene que ser estático (Shared en VB.NET) y el primer parámetro debe ser el tipo del que se va a extender, en nuestro caso será un arreglo de enteros ( int[] ):

namespace PruebaPares{

public static class Extensiones{

public static int[] Pares(this int[] arreglo){

}

}

}

Observe que el tipo que devuelve es un arreglo de enteros con los resultados, es decir, con los números que son pares.

Voy a implementar este método utilizando LINQ, una tecnología, la cual merece un post (varios diría yo..) aparte:

namespace PruebaPares{

public static class Extensiones{

public static int[] Pares(this int[] arreglo){

IEnumerable resul = from p in arreglo
where (p % 2) == 0
select p;


return resul.ToArray();

}
}

}

Lo que hace esa consulta en LINQ es recorrer el arreglo y buscar los elementos que cumplen la condición en la cláusula 'WHERE', para quienes conozcan algo de SQL, verán esta sintaxis muy parecida. Bueno, después que filtra los resultados, lo convertimos en un arreglo de enteros y lo retornamos, así pues, un ejemplo para utilizar este método, y llamarlo de manera 'decente' sería así:



class Program
{


static void Main(string[] args){

int[] arrayEnteros = new int[]{2,3,4,5,7,8,9};

Console.WriteLine("Numeros pares");

foreach (int x in arrayEnteros.Pares()) {

System.Console.WriteLine("Numero :" + x);

}

System.Console.ReadLine();

}

}

jueves, 9 de julio de 2009

Aprende a Programar con Small Basic











Para los 'principiantes' en el maravilloso mundo de la programación, este enlace para la descarga del tutorial de Small Basic en español gratis.

Este tutorial muestra los primeros pasos en condiciones, sentencias, bucles, etc.
Y también gráficamente (e insisto en español) muestras para realizar programas sencillos y algunos algo complejos: Explica cómo hacer el juego del Paddle o cambiar el fondo del escritorio aleatoriamente, etc.
Algunos programas de juegos que se pueden hacer con small basic (con codigo fuente):




También el link para que descarguen el programa 'Small Basic' y empiecen a hacer sus pininos con la programación:

Pdt. Ojalá y me hubieran enseñado este tipo de herramientas cuando empecé, pero no!!, todo en el crudo Turbo C, me hubieran ahorrado unas cuantas desveladas jaja. Así que.. Aprovéchenlo..

Gracias por el aporte a Fernando Machado y Sandra Aldana.

miércoles, 1 de julio de 2009

Seis errores comunes en entrevistas con los clientes

De esto no hay mucha relación con .NET, pero es igual de importante para el trato con los clientes que no tienen mucho o nada que ver con las Tecnologías de la Información, es decir, no lo conocen, lo conocen muy poco o ellos creen que lo conocen.

Lo hago, por que la corta experiencia que tengo, me ha servido para no cometer 'errores' al platicar o proponer algun proyecto, y esto después después de leer libros como Ingeniería de Software, donde te proponen pláticas y entrevistas con los clientes de una cierta manera, pero en la vida real...., pues es otro asunto.

Cuando trates con un cliente, él te abordará diciendo algo como....
  • "Necesito un sistema que...."
  • "Quiero una página que maneje...."
  • "Quiero imprimir directamente..."
  • "Quiero tener un inventario de...."
  • "Necesito controlar a...."
Primer error: en la misma platica nosotros estaremos pensando en una base de datos, en un lenguaje de programación, en una cierta tecnología, incluso hasta la vista de cómo quedará nuestra aplicación.
No pienses en nada de eso, sólo escúchalo y déjalo terminar, pon atención muy bien de los detalles que te menciona... es en los 'detalles' donde radica la verdadera lógica o problema que necesita resolver.

Después de todo el rollo del cliente, termina diciéndote algo como:
  • "Y.. como cuánto me costará?..."
Segundo error: Cotizar de manera inmediata el proyecto, nosotros hacemos un cálculo mental de lo que nos llevaremos en hacer todo (la base de datos, la aplicación, etc.) y terminamos por dar un precio que asusta al cliente. (jaja, sí, a todos nos pasa eso al principio)
Para poder dar una cotización tienes que ANALIZAR detenida y detalladamente todas y cada una de las actividades que vas a hacer.... si tienes que hacer documentación, si tienes que modelar una base de datos, si tendrás que ponerle imágenes o inclusive un 'estilo de vista' a la aplicación (en páginas web, pues fijate si harás las hojas de estilo y diseñarás las capas de la página, o harás como muchos... tomar templates y modificarlos...). No des un precio final en menos de 5 minutos... ni si quiera lo has pensado bien!!!, aunque el cliente te presione para darle un precio, debes de ser profesional..., tienes que ver qué actividades vas a hacer y en qué tiempo las piensas realizar.
Tercer error: empezar a hablarle en términos técnicos que sólo los desarrolladores conocen, con términos como 'bases de datos' (en serio, pregúntale que entiende por base de datos, y en algunos casos te sorprenderán de lo que piensan), 'Aplicación distribuída', 'Software en capas', 'servicios', 'cloud computing', 'minería de datos', 'dominios, subdominios', mucho menos le digas 'HTTP', 'CSS', 'SOAP', 'XML', etc., etc.
Al platicar con el cliente sabrás por la manera en cómo describe los procesos y cómo cree que se pueden solicionar o 'automatizar' el nivel de conocimiento que tiene sobre las TI, y aunque se vea que sabe mucho, trata de hablar siempre en términos que hasta un niño pueda comprender... Dile que la página web se verá 'bonita', 'interactiva' y fácil de entrar y navegar, que la aplicación almacenará 'automáticamente' los datos, que sus datos estarán disponibles cuando lo necesite, que el procesamiento será muchísimo más rápido, dile que al usuario le facilitará la vida (aunque tu te la compliques).
Cuarto error: nunca utilices las palabras 'creo que no se puede' cuando analices un proceso que el cliente lo tiene en su cabeza (o inclusive por escrito).
Empezando por el 'creo' que se escucha como a qué no lo puedes hacer y con el 'no se puede' que describe lo ineficiente que te ves en ese momento. Al cliente no le importa si tienes que utilizar hasta 10 tecnologías al mismo tiempo, o si utilizas un proceso complejo de sincronización, análisis, entrega, comparación, etc. Lo que realmente le importa es que su trabajo se haga y se haga bien.
Quinto error: Hacerte el que todo lo sabe y dejar los pequeños detalles a un lado, como te decía, es ahí donde debes enfocarte. Comunmente en las entrevistas sólo haces las preguntas necesarias y listo.
En cuánto más información tengas del funcioamiento de 'todo' lo que se pueda y no computar, es mucho mejor, así tienes límites (en todas las aplicaciones hay límites) para saber lo que vas y lo que no vas a contemplar. Pregunta cómo quiere se imprima un reporte, en qué formato, cómo hacen para la captura de datos (con qué están mas familiarizados... Páginas o aplicaciones de escritorio), qué tipos de máquinas son con las que cuenta o piensan contar, hasta la edad y experiencia de los usuarios en sistemas de cómputo. Todas esas preguntas que tienen o no que ver con el sistema debes saber para establecer los límites.
Sexto error: Darle opiniones espontáneas para 'mejorar' los procesos o problemas que vas a resolver con tu desarrollo.
Si bien es cierto que es nuestra obligación informarle al cliente de las maravillas que las computadoras hacen por nosotros, y que pueden hacer con su negocio, trata de medir bien las palabras que dirás, porque o le pueden fascinar, o quizá te tache de un loco. Por mas que creas que tus ideas mejorarán (y aunque así lo sean) su negocio, no te desesperes, quizá hasta el mismo cliente te dé la respuesta que necesita (lo que sucede casi siempre) aunque no sea la mejor opción.
Espero y te haya servido de algo, y si tienes algunos otros errores que puedas comentar (que yo sé que hay muchísimos más) son bienvenidos.