Quique´s Blog o el Blog de Quique

Ayer en el Hol de programación multihilo, un tema fascinante, del que no conocía muchas cosas, como que sólo pueden correr simultáneamente 25 hilos por procesador (sino entendí mal); nos hizo recapacitar una cosa: Esta muy bien eso de los 25 hilos, los semáforos, los Mutex, las llamadas asíncronas, etc. pero el tema que más nos preocupa es ¿Cuando aplicamos eso?. Esta es una pregunta que muchas veces nos hacemos, sabemos de algo, es interesante, pero cuando debemos aplicar un thread, un background worker, un multihilo... Creo que ese es uno de los grandes misterios de la informática, nos saturan con muchos conocimientos, muchas cosas nuevas, o no tan nuevas, pero luego después de descubrir las ventajas de los mismos se te plantea la duda de cuando aplicar uno u otro, es demasiado para lo que quiero?? las implicaciones que lleva el desarrollar compensa el tiempo invertido??, resuelve lo básico??. Creo que debería haber en las charlas, conferencias, HOL... una parte dedicada a cuando deberíamos aplicar todo lo aprendido, me refiero desde el punto de vista del programador para saber en qué caso sería conveniente aplicarlo. Creo que esta pregunta muchos profesores, charlatanes  conferenciantes,  no sabrían contestar a muchas de este tipo por que seguro que ni la han aplicado, cosa que veo normal, porque cuando lanzas 25 hilos simultáneamente… Creo que este es un tema que debiera reforzar Microsoft, el saber explicar cuando, donde y por qué utilizar las herramientas, opciones y todo lo que da y tienes a tu alcance para ser mas eficiente en tu trabajo diario (que es el que te da de comer).

¿Cuantas veces hemos querido recorrer un enumerador sin tener que asignar valores?, ¿Sin tener que saber el numero de elementos?....

El otro dia hice una funcion, que lo conseguia pero no me gustó era muy larga así que buscando mas en la web descubrí esta otra forma de hacerlo:

foreach(Enumerador nombre_enum in Enum.GetValues(typeof(Enumerador)))

{

//Acciones

}

Así que ya sabes si necesitais recorrer un enumerador....

Cuando desarrollamos una aplicación, siempre empezamos a escribir código, normalmente no le damos importancia a las líneas que tiene un formulario, qué más da si tiene 100 o 1000, en teoría no vamos a mantenerlo, pero en la mayoría de los casos esto no es así, nosotros no fallamos son los usuarios los que lo han hecho mal, mi código está revisado y probado. En el proyecto que estamos desarrollando esto no es así, medimos cada línea de código que escribimos, mimamos cada detalle, si esto tiene sentido o no… hemos pasado 4 meses haciendo la base, todo para qué (uhmm 4 meses de trabajo, 2 programadores, podíamos haber hecho unos 50 o 70 mantenimientos), todo para reducir las líneas que hay que escribir. Ahora los mantenimientos no llegan a 100 líneas con los métodos que asignan a los controles los datos… Si quitamos los métodos Get/Set de los datos nos quedan los formularios en 15 líneas. Así que ahora tras pasar unos meses malos haciendo, rehaciendo, haciendo, rehaciendo… Hemos conseguido que para hacer un formulario simplemente con pegar los controles en el formulario y configurar 4 cosas en 2 horas tengamos un mantenimiento. Esto sí que mola. Como lo hemos conseguido (Incluso con la aplicación en 3 capas):

·        Usamos un modelo de entidad, con atributos. En los objetos tenemos todo lo que necesitamos de la base de datos, tamaño, campos clave, longitud… El modelo de entidad es multientidad, o mejor dicho con subentidades, esto costó algo mas pero lo conseguimos.

·        Tenemos la capa de acceso a datos genérica, al usar el modelo de entidad, usamos una interfaz tanto para las entidades como para la capa de acceso a datos. En la capa de acceso a datos podemos usar cualquier tipo de entidad, construyendo las sentencias SQL en tiempo de ejecución, esto fue algo más costoso, para lograrlo usamos Generics, Tipos <T>.

·        La capa de negocios, es casi estándar, nuestra capa de negocio nos resuelve el módulo  genérico en el 90% (así que no tenemos que escribir mas que 2 líneas para definir el tipo de entidad que va a usar) de la misma, no son genéricos los módulos en los que queremos que una entidad actualice datos en otros, así que sobrescribimos funciones, esto pasa mucho en los modelos multientidad. Usamos interfaces, Tipos <T>,…

·        En la capa de presentación usamos la herencia visual, en la que definimos en el formulario base las funciones de bloqueo, desbloqueo, los menús, las acciones de los menús etc etc, así cuando heredamos de este formulario tenemos todo controlado.

En total la base tendrá unas 3000 líneas, a partir de ahí empezamos la aplicación de 0.

Es importante haber perdido este tiempo creando la base? Yo creo que si, aunque tengo que reconocer que al principio fui un poco escéptico sobre esto, pero ahora cuando lo ves te das cuenta de lo importante que es tener poco código, porque hay poco que mantener menos probabilidades de fallo y menos tiempo en la depuración. 

En las empresas es difícil que acepten el perder este  tiempo, pero por suerte o por desgracia el gerente aceptó el “perder” este tiempo, si el proyecto es pequeño y no tenemos esta base entiendo que no merece la pena, pero a un proyecto estimado a varios años si es importante tenerlo así, por la buena marcha de todo.  

Herencia Visual, uhmm herencia visual…

¿Cuantas veces hemos copiado y pegado el mismo menu? ¿Cuantas veces tenemos la misma barrita dichosa?....

¿Qué es la Herencia Visual?

Voy a decirlo a groso modo que es para mí la Herencia Visual. Es una "herramienta" de la POO en la que a partir de un formulario podemos tener otro basado en este primero, es decir, diseñamos un formulario y cómo podemos heredar de él en C# , obtendríamos como resultado un formulario como el primero pero con la ventaja de tener todas las propiedades, métodos, eventos y funciones del formulario base, pudiendo extenderlas, aumentarlas y sobrescribirlas, pero no solo en el código sino también de forma visual. La herencia visual es una parte imporante para los que tenemos una gran carga de formularios en los proyectos, siendo la mayoria muy similares, con mucha funcionalidad similar, ayudandonos bastante en la confección de los formularios y el diseño de los mismos, ya sabeis cuanto menos codigo escribamos menos codigo hay que mantener menos errores tendremos despues de depurar (gracias Juanete por enseñarme esto)…

Algunas de las ventajas que tenemos con este tipo de herencia:

Podemos mantener una misma interfaz de forma sencilla, simplemente creando un modelo base y derivando de este, con lo cual mantendríamos el mismo diseño

Crear funciones para todos los formularios, simplemente con una implementación en el formulario base, sin tener que hacer llamadas especiales, ni tener que implementarlas en cada formulario.

Implementar funcionalidad nueva de forma rápida y sencilla, es decir, pensemos que tenemos 100 formularios y nos piden los usuarios que metamos un botón en el menú para la modificación de informes, pues bien con este método seria rápido y fácil debido a que implementado en el formulario base dicha funcionalidad lo tendríamos en todos los formularios

Nos permite aumentar la funcionalidad específica de cada formulario, es decir, tenemos el formulario base con cierta funcionalidad, pero hay un botón que requiere de una funcionalidad nueva, pues bien haciendo un override nos permitiría cambiar dicha funcionalidad.

 

Vemos un ejemplo:

Creamos un Proyecto en blanco o mejor añadimos un formulario al proyecto de Pruebas que tengamos… en dicho formulario creamos el diseño del mismo... como en la siguiente imagen...

 

 

 

 

Una vez conseguido esto… Añadimos un nuevo elemento… Podemos hacerlo de 2 formas, una derivando directamente de este control, es decir cuando añadamos un nuevo formulario entramos en el código fuente y cambiamos la derivación de: form a: FrmBase, con lo cual tras la recompilación nos debería salir una copia de este formulario. La otra forma que hay es… una vez nos salga la pantalla de agregar un nuevo elemento, elegimos la opción de formulario heredado, seguido nos debería aparecer una papara seleccionar el formulario sobre el que queremos derivar. OJO siempre acordarse de compilar antes y que la compilación sea satisfactoria, sino no saldrá el formulario y no podréis derivar.

El resultado tiene que ser algo así:

 

 

 

 

 

Así tendríamos el botón base...

 

En la segunda  parte profundizaremos en el código…

 

Si alguien quiere el código que mande un email a: erodriguez@sofiscom.net y se lo pasare encantado

using System;

namespace My.Blog
{
    public class Person
    {
        public Person()
        {
            Name = "Enrique Rodriguez Rio";
            Dateofbirth = new DateTime(1980,10,30);
            Location ="Solares, Cantabria (Spain)";
            Company = "Talleres Oran S.A.";
            Occupation = "Programmer";
            MyLanguages lan = new MyLanguages();
        }
        private string _name;

        public string Name
        {
            get
            {
                return _name;
            }
            set
            {
                _name = value;
            }
        }
        private DateTime _dateofbirth;

        public DateTime Dateofbirth
        {
            get
            {
                return _dateofbirth;
            }
            set
            {
                _dateofbirth = value;
            }
        }
        private string _location;

        public string Location
        {
            get
            {
                return _location;
            }
            set
            {
                _location = value;
            }
        }
        private string _company;

        public string Company
        {
            get
            {
                return _company;
            }
            set
            {
                _company = value;
            }
        }
        private string _occupation;

        public string Occupation
        {
            get
            {
                return _occupation;
            }
            set
            {
                _occupation = value;
            }
        }
       
        private enum MyLanguages { C_Sharp, VB_Net, Vb_60, Asp_Net, Asp, SQl_Server }
       
       
    }
}

Ahora estoy leyendo "The Pragmatic Programmer: From Journeyman to Master", un libro sobre el que he leído que es imprescindible... sobre todo en mi búsqueda del santo grial ( el código perfecto), iré llamando a Harrison para que me ayude...

Algo más sobre el libro

The pragmatic Programmer

Si alguno lo habéis leído, comentemos que tal es, que nos/os ha aportado..

El otro día estaba cambiando la base del proyecto, lo habíamos cambiado todo de usar tipos object a tipos T ( generics), cuando estaba probando la interfaz de usuario, yo creía que lo había cambiado todo, que todo creaba bien las sentencias SQL (lo sé hay que usar pruebas unitarias, pero....) y bueno todo iba muy bien hasta que le di al botón borrar... de repente todos los datos se fueron de vacaciones y no sé si se han ido a buscar a curro porque aquellos datos no han vuelto... Menos mal que tengo acceso a restaurar la copia de seguridad y restaurar los datos de la tabla y los repuse....

 

Moraleja: Siempre revisar cuando cambies algo que os genere las sentencias automáticamente, las sentencias Update y Delete para que os lo haga bien porque sino  aprenderéis mucho a restaurar copias de seguridad de la base de datos.

Moraleja (II): Haced copias de seguridad regulares de los datos de vuestra base de datos de pruebas... para que si perdéis no perdáis mucho....

Hoy quiero inaugurar esta sección en la que contare, y espero que contéis vuestras mayores meteduras de pata, simplemente para reírnos un rato juntos, si si podéis reíros de mi si queréis...

 

Así que animaros a contar vuestras meteduras de pata, fallos que hayáis tenido... ya sea de programación o de lo que consideréis....

No os habeis preguntado alguna vez, cuantas lineas de codigo tiene tu proyecto??, yo siempre, pero es que ponerse a contar todos los modulos cansa... (jejjejeje), seguro que hay millones de herramientas pero os voy a hablar un poco de una herramienta que se integra con el VS 2005, y con el 2003 tambien... se trata del Dpack, que podeis encontrar en: Dpack

Con esta herramienta podeis :
1.- Crear un backup de vuestro proyecto en un .zip... de forma facil simplemente pinchando y diciendo donde guardarlo
2.- Podeis buscar en toda la solucion, y podeis restringir las busquedas solo a clases, a interfaces, methodos, propiedades...
3.- Podeis buscar archivos en toda la solucion...
4.- Podeis buscar en todo el Framerwork
5.- Y lo que a mi mas me gusta las estadisticas:
    Donde te cuentan Las lineas escritas, las comentadas, el lenguage usado, las lineas vacias, el numero de archivos por modulos....
Que no sirve de demasiado pero por curisidad, la base de nuestro proyecto ( que esta a un 80%) tiene unas 35641 lineas de codigo,  8371 lineas de comentarios , 5966 lineas de codigo en blanco con lo cual el proyecto tiene unas: 49978 lineas en 224 archivos... y todo esto tambien te lo desglosa por modulo... jejeje esta bien saber al final del dia cuantas lineas has escrito...
Pero tiene una parte negativa, tu jefe siempre controla cuantas lineas has escrito por dia, si tiene un control de codigo al estilo Source Safe que todos usareis seguro....

y lo mejor de todo es totalmente gratis!!!!! asi que no busqueis crack que no hace falta :p

Llevo programando o mas bien intentando escribir codigo sin fallos (si, si ya lo se, no existe el codigo perfecto, pero bueno de ilusiones vive el hombre), cerca de 3 años, desde que acabe la carrera, y desde entonces me he centrado en programar en lenguajes del tio Bill, pero en estos tres años, he pasado de VB 6.0 a VB.net 2003, del 2003 al 2005, del ASP normal al ASP.net.. y de todo eso a C#, cuando empece con el C# por aquel mes lejano de Febrero del 2006, ya no sabia si el for llevaba parenteis, llaves, corchetes o si existia un for.... pero bueno a todo se hace uno con ganas, ilusion, un jefe que te quiera enseñar (lo  que no sabes o desconoces) y muchas horas de estudio y dedicacion (pero bueno que le vamos a hacer). Ahora estamos en la empresa con un modelo de entidad basado en 4 capas  propio(echo por nuestros dedos), con un Mappeador de datos generico basado en generics, reflexion tipos T, con un generador de los modelos de entidad creados por nosotros, para los que no sepan que es eso: a partir de una tabla de la base de datos, le das a un boton y de repente por arte de "magia" y muchas horas de depuracion aparece un archivo (.cs), con todo lo que hay en la tabla de la base de datos en el fichero,los campos, las propiedades todo con sus atributos... y cuando ya lo teniamos mas o menos echo alla por junio, te enteras que hay un archivo que sacó en mayo micro para decirte que la siguiente version del VS (probablemente para el 2008),  ya te incorporá un modelo de entidad,  de la que ya han sacado la primera CTP que obviamente ya hemos probado y que de momento no nos termina de convencer, así que de momento consideramos que lo  mejor es lo que nosotros hemos echo que hace exactamente lo que queremos y necesistamos, aunque no niego que es una pasada... pero a lo que quiero ir es... en menos de 5 años vamos a pasar por 3 versiones de VS, y cambiando en todas la forma de tirar lineas a la pantalla... y claro cuando pretendes llamarte experto en alguna version van y te la cambian.. el fin justifica los medios?, ¿es bueno estar al dia en todas las versiones de micro? ¿es necesario estar a la ultima? y para los que no sean millonarios o no tengan una suscripcion a la MSDN ¿Es bueno quemar la tienda del emule bajando  versiones?....
Segun como yo lo veo: Micro vive de esto de vender productos,libros..., a los que nos gusta esto seguiremos a microsoft hasta que nos aburramos, no podamos estudiar, nos dediquemos a trabajos varios (peluqueria, pasteleria, panaderia o cualquier otro tipo de actividad en la que todos pensamos en dedicarnos) o peor aun estiremos la pata... pero en tu trabajo diario compensa tanto cambio? ¿Quieres que tu empresa este a la ultima, tenga lo mejor de lo mejor, la ultima tecnologia?. Peor aun es si tienes un proyecto largo a unos 3 o 5 años cuando quieres acabar con una version del VS ya tienes la siguiente version... con lo cual llegara un punto en el que tienes que parar y decir: "¿Necesito la siguiente version?..." y problamente si tu gerente quiere estar a la ultima te dirá... Implanta y mientras se prueba lo adaptas a la siguiente versión... esperemos que los conversores de versiones de microsoft mejoren para las siguientes versiones... porque sino me veo con el VS 2005 hasta el 2010 y en 2010 ya veremos que pasa... Seguro que muchos os sentis como nosotros. Pero a veces el fin no justifica el readaptar todo, porque claro si microsoft saca versiones cada poco tiempo, las versiones tienen cambios pequeños el cambio en readaptar no es muy grande, pero si hay cambios grandes que es lo mejor para hacer.... (lo dejo para opinion de cada uno, que cada uno sabe cual es su sitiuacion) Espero haberme explicado y que entendais que es lo que prentendo deciros, pero seguro que muchos os sentis como nosotros....