José Selesan

¿Cómo ser mejor programador?

2010-12-13T12:54:00.001-03:00

Hace algunas semanas que tengo pensado escribir sobre esto, y ayer casualmente me encontré con este post del maestro Ángel Lopez, post que me pareció totalmente acertado, sobre todo en tres puntos: leer (leer mucho), pensar y escribir código. No se si lo leí o se me ocurrió a mí, pero hace años que sostengo (y se lo recuerdo permanentemente a mis alumnos) que a programar se aprende programando. La teoría es útil, sirve para tener una base sólida sobre la cual asentar la práctica, pero en la profesión de programador, es fundamental programar y programar y programar.

A la lista de Ángel me gustaría agregar, como tarea para todo programador, la participación en listas y grupos de discusión. Actualmente hay infinidad de listas y grupos en inglés y en español, son gratis y generalmente cuentan con la participación de muchísima gente. Los grupos de discusión son útiles tanto para programadores junior como para aquellos que ya cuentan con sus años de experiencia. Para un programador junior, ser miembro de un grupo de discusión implica ni más ni menos que un desfile de posibles nuevos conocimientos, ya sea porque alguien le responde una pregunta o por ver respuestas a preguntas de otros. En este segundo caso, es donde creo que las listas y grupos cumplen un rol muy interesante en la vida de los nuevos programadores. Muchas veces, los programadores jóvenes no cuentan con un tutor o guía o como quiera que se llame al programador más avanzado que lo lleva por los rumbos del conocimiento, entonces, al formar parte de grupos de discusión, se va a encontrar de repente con un desfile de potenciales nuevos conocimientos. Muchos de ellos van a llegar también como consecuencia de la tarea de publicación y comunicación de resultados de programadores experimentados que comparten su conocimiento con los demás. Eso sí, la inquietud por la lectura y el conocimiento deben estar presentes; en un post de una lista o una respuesta a una pregunta, puede aparecer una punta de iceberg, pero el programador deberá sumergirse durante un buen tiempo para observar el iceberg por completo.

Debo reconocer que en mis primeros años como desarrollador, las listas me abrieron la cabeza mostrándome un mundo de conocimientos nuevos (ahí conocí muchos patrones, libros, frameworks como NHibernate, MonoRail, etc).

Cabe aclarar que las listas no solo servirán para programadores que se inician. Todo lo antes expuesto aplica para cualquier programador: siempre hay alguien que sabe más, o sabe cosas que no sabíamos…

Por último, para ser mejor programador, hay que tener siempre presente lo expuesto por Martín Salias en su post “Antipatrones: no tengo tiempo”

La necesidad de estar ocasionalmente conectados

2010-11-22T20:57:00.001-03:00

O mejor dicho, la necesidad de estar ocasionalmente desconectados. Esto viene a cuenta porque en los últimos meses tuve oportunidad de recibir a varios posibles clientes (de sistemas nuevos o de enlatados), planteando la necesidad de poder utilizar el sistema en su portable tanto en la empresa como en su casa o en cualquier lugar donde se encuentre.

Esto hace evidente la inserción de las computadoras portables en la vida de los usuarios de software, y también hace evidente la necesidad de plantear los desarrollos con características de lo que en inglés se conoce como OCA (Occasionally Connected Applications), es decir que no están siempre conectadas sino solo de manera ocasional. Por conectadas entendemos con acceso a la red local de la empresa, por lo tanto una aplicación de software “ocasionalmente conectada” será aquella que pueda usarse aún cuando no se tenga acceso a la red local. Queda claro que queda fuera de este planteo el uso de protocolos HTTP para pasar por proxies sin problemas, ya que ello implica un servidor expuesto en Internet, con una dirección IP fija (o en su defecto un DNS dinámico), pero sobre todo la necesidad de contar con una conexión a Internet lo suficientemente decente y estable, pero ello sigue sin ser garantía para que los usuarios pueda usar la aplicación desde una red distinta a la de la empresa, ya que eso sería aceptar algunas de las falacias de la informática distribuida, tal como cita Ayende en éste artículo.

Microsoft ya tiene su propuesta para el desarrollo de aplicaciones con soporte para OCA (el Microsoft Sync Framework), que si bien soporta sincronización entre varios tipos de base de datos, está fuertemente orientado a SQL Server 2008.

En definitiva, creo que llegó la hora de tomar en cuenta el uso desconectado a la hora de plantear los requisitos no funcionales de una aplicación, y de tenerlo presente a la hora de definir la arquitectura. Y con ello llega también la hora de estudiar las alternativas actuales para realizar la sincronización de los datos o de empezar a pensar en desarrollar un mecanismo propio.

Ser profesional de Sistemas

2010-05-21T00:20:00.001-03:00

Desde hace años noto que en el común de la gente sucede algo extraño con respecto a nuestra profesión. Si bien no me sorprende, me parece raro que a esta altura del partido, la mayoría de las personas “ajenas” al mundo del software y de IT sigan sin comprender los alcances de un profesional de sistemas.

Ante la pregunta “¿Y vos a qué te dedicas?” , son muy pocos (realmente pocos) los que enseguida entienden y nos dicen frases como “que interesante”, o “esa es la profesión del futuro” (esta última la vengo escuchando desde hace no menos de 20 años). La gran mayoría sin embargo no logran ni lograrán comprender la dimensión de lo que hacemos, o qué significa realmente trabajar en lo que trabajamos.

Típicas reacciones a nuestra respuesta “Trabajo en Sistemas”

- ¿Arreglás computadoras? ¿sos técnico?

- Me viene al pelo, vos sabés que me parece que tengo un virus, ¿Vos me lo podés sacar?

- ¿No me ayudás a instalar tal o cual "jueguito"? (llamarle "jueguito" a complejas piezas de software merecería un post por sí mismo)

Esto es lo mismo que preguntarle a un ingeniero mecánico donde tiene el taller para llevarle el 4L que está quemando mucho aceite.

Sin duda esta gente no se imagina que uno estudia 5 o 6 años para formarse como profesional de sistemas, lo mismo que estudia un ingeniero para construir puentes o un contador para ~~robarle~~ administrarle las monedas a una empresa, o un abogado para hacer de las suyas. Y ni hablar que los que trabajamos en sistemas no terminamos nunca de estudiar, que la tecnología corre más rápido que nosotros obligándonos a ir distraídos por ahí meditando algo que leímos sobre lo último en materia de software o de tendencias o de lo que sea. O peor aún, que nuestra profesión exige que estructuremos nuestros cerebros para poder hacer todos los días tareas de una complejidad bastante grande, convirtiéndonos en seres raros e incomprendidos por personas más “simples”.

Este comportamiento ya bastante generalizado tiene una consecuencia muy nefasta en nuestra profesión: la dificultad de muchos para entender por qué nuestro trabajo cuesta lo que cuesta. Salvo contadas excepciones, ante un presupuesto por un proyecto de desarrollo o una simple modificación de un sistema, muchos se espantan como si les estuviésemos a punto de robar. Muchos discuten el precio, pretendiendo tener autoridad en el tema, otros directamente nos dicen que estamos locos y que van a buscar a otro (unos párrafos más adelante vuelvo sobre este tema). ¿Pero que se piensan? ¿Acaso ponen en duda el precio cuando un escribano les cobra por poner una firma? ¿Por qué a los demás no y a nosotros sí? Recuerdo que una vez fui al odontólogo y luego de unos 30 o 35 minutos terminó su trabajo y me dijo “Listo, pero tenemos un problema con tu cobertura de salud, te cubre solo 30 pesos y este trabajo cuesta 90. Yo por 30 pesos me quedo cortando el pasto”. Por ese entonces yo pretendía cobrar 25 pesos la hora y no lograba que nadie acepte ese precio.

Tratando de entender las causas de las mencionadas reacciones, se me ocurren dos posibles explicaciones. Por un lado está el qué no entiende qué es lo que hacemos porque de computadoras solamente sabe lo que escuchó a la pasada en algún lugar, pero las ve como un bicho raro (y obviamente ni sabe de la existencia de términos como “software”). Estos son los menos nocivos. Los otros son los que al escuchar que trabajamos en sistemas, asocian inmediatamente sistema con computadora, y computadora con el hijo de la vecina, que está todo el día (o la noche) sentado frente a un monitor, comentando fotos en Facebook o juando al Poker en Internet. De ahí que creen que hacemos lo mismo que el pibe. Se equivoca señora, nosotros no hacemos lo mismo que hace el nene, nosotros creamos las tecnologías con las que el nene se entretiene. Pero eso no lo va a entender. Muchos creen que el software brota de los monitores como hongos en la lluvia.

En relación a esto último, y volviendo al tema de los aranceles, lo del nene que “sabe algo de computadoras”, lleva a muchos a creer que porque sabe instalar jueguitos o conoce trucos de algunos programas, pueden hacer nuestro trabajo. Entonces, ante la presentación de un presupuesto por nuestro trabajo, nos dicen “Noooo, estas loco, le voy a decir al hijo de la Cuca que lo haga, el sabe mucho de computación”

Es así doña Rosa. Los que trabajamos en sistemas hemos estudiado, y mucho, en una Universidad (no hicimos cursos de computación). Hacemos un trabajo calificado que no es nada fácil (yo puedo manejar un colectivo por la ciudad, ¿un colectivero puede decidir la arquitectura de un nuevo sistema de software?). Así que no nos trate como a unos improvisados como el hijo de la vecina.

Aunque sospecho que doña Rosa nunca va a leer este blog…

Y un día volvió

2010-05-13T17:11:00.001-03:00

Por fin después de casi un año y medio, he decido firmemente retomar la escritura en el blog. Hay varios temas rondando mi cabeza, algunos directamente relacionados a la programación y otros no tanto, pero que me interesan igual o más que el desarrollo de software y por eso quiero publicarlos.

Una de las motivaciones más importantes para retomar el blog es la lectura diaria de los posts del gran maestro Ángel “Java” López (http://twitter.com/ajlopez), a quien admiro y sigo desde hace unos cuantos años. En alguno de sus tantos posts, hablaba de la importancia de compartir lo que se aprende con los demás miembros de este extraño mundo de los desarrolladores de software. Y eso nuevo que se aprende puede ser la forma de resolver un complejo algoritmo, el análisis de un libro, una idea para un proyecto, o lo que fuera.

Así que aquí estaré. No se si voy a poder escribir un post diario, pero sí espero hacerlo con cierta frecuencia.

Y como dice el maestro, “nos leemos”.

ASP.Net MVC, routing y URL amigables

2008-11-26T15:15:00.003-02:00

Creo que una de las cosas que más le gusta a los webmasters son las URL amigables, por todo el tema de Google y de posicionar la página. Para los que no saben de qué estoy hablando, lo resumo fácilmente: una URL del tipo www.dominio.com/productos?id=4525 no dice mucho en sí misma sobre qué es el producto y es difícil de recordar, por eso se dice que "no es amigable", una URL amigable en cambio, sería de la forma www.dominio.com/catalogo/navegadores/gps-nuvi-200. En esta url claramente vemos que se trata de un producto dentro de la categoría "navegadores" y su descripción es "gps-nuvi-200". Además de ser lindas para los simples mortales, las URL amigables son muy buenas para los motores de búsqueda. En wikipedia hay más información (note usted la URL amigable en la mismísima wikipedia).

Ahora bien, implementar URL amigables en ASP.Net nunca fue tarea fácil hasta la llegada de ASP.Net MVC. Con este nuevo framework podemos crear rutas, que no son más que formas de indicarle al motor como traducir una url en una llamada a una acción de un controlador.

Para ilustrar mejor vamos a ver un pequeño ejemplo. Supongamos que tenemos un controller llamado ProductosController, con una acción llamada Ver que tiene como objetivo mostrar un producto cuyo código único recibe como parámetro. Sin usar rutas, una url típica sería de la forma /productos/ver/4525. Vamos entonces a crear una ruta para hacerla más amigable.

En ASP.Net MVC, las rutas se registran en el evento Application_Start y se evalúan de la primera a la última, cuando una corresponde ("matchea" se podría decir, aunque no me guste hablar así) con la url, es esa la que se usa. Para nuestro caso, la ruta quedaría así:

routes.MapRoute(

"Catalogo",
"catalogo/{id}/{descripcion}",
new { controller = "Productos", action = "Ver", id = 0 },
new { id = @"\d+" }

)

El primer parámetro es el nombre de la ruta (que debe ser único", el segundo es el patrón de la url y el tercero es el que indica los valores por defecto. El cuarto parámetro lo veremos luego. En los valores por defecto le estamos diciendo que si no puede detectar el nombre del controlador en la url, que use "Productos" y que si no puede encontrar la acción, que use "Ver". Con esta ruta, al llamar a la url /catalogo/4525/gps-nuvi-200 en realidad se estará llamando al método Ver de la clase ProductosController, pasandole el valor 4525 como parámetro.

Vamos a hacer un poco más interesante la url. Supongamos que queremos dar la posibilidad de colocar la categoría del producto en la url, o sea algo de la forma /catalogo/navegadores-satelitales/4525/gps-nuvi-200. Para hacerlo, basta con agregar otra ruta más de la siguiente forma:

routes.MapRoute(

"CatalogoConCategoria",
"catalogo/{categoria}/{id}/{descripcion}",
new { controller = "Home", action = "Prueba", id = 0 },
new { id = @"\d+" }

);

En esta nueva ruta, hacemos casi lo mismo que en la anterior, con la diferencia que ahora estamos esperando urls con la categoría antes del ID de producto. Lo importante de esto es el cuarto parámetro que no expliqué hoy. Ese parámetro no es más que una restricción sobre los elementos de la URL, y le indica al motor de ruteo que la url corresponde con esa ruta si se cumple esa condición. En nuestro caso, le estamos diciendo que el ID debe ser un número. Esto es muy importante porque si no lo hacemos, al recorrer las rutas en orden, el motor tomaría la categoría como ID de producto, dando un comportamiento que no es el esperado.

Error inesperado

2008-11-14T21:56:00.002-02:00

Por esas cosas locas que tiene el destino, saqué de nuestra biblioteca una vieja edición de "Sobre héroes y tumbas" y entre sus maravillosas páginas había un pequeño trozo de papel escrito por mí y que quizá en su momento sirvió de señalador, con el texto "A class named TInterfacedPersistent already exists", y se me dió por pensar no sólo los años que debe llevar eso ahí, sino también por qué lo abré anotado y en qué habré estado trabajando en ese momento. Por la T al principio del nombre de clase se me ocurre que es Delphi, pero vaya uno a saber.

Es interesante lo que uno puede encontrar abriendo un libro...

Advantage Database Server y ASP.Net 2.0

2008-11-14T16:23:00.002-02:00

Estoy trabajando en una aplicación web con Visual Studio 2008 y Advantage Database Server como motor de base de datos y ocasionalmente, al ejecutarla obtenía un error diciendo que no se podía hacer un typecast entre el tipo de dato System.Web.Compilation.BuildResultCompiledAssembly y el tipo System.Web.Util.ITypedWebObjectFactory. Lo extraño es que recargando la página en el browser con Shift presionado para que la traiga toda de nuevo, funcionaba bien.

Buscando un poco en internet, encontré este KB de Microsoft donde explican las causas y la solución. Aparentemente no le gusta mucho tener ensamblados satélite con información de cultura, así que mirando las propiedades de cada assembly de mi solución, encontré que las causantes del problema eran tres dlls que necesita el provider de ADS para .Net: ace32.dll, adsloc32.dll y axcws32.dll. Después de colocarlas en una carpeta llamada en-US dentro del bin, todo funcionó de diez, y fuimos felices.

ASP.Net MVC y la extensión .mvc

2008-10-30T14:30:00.004-02:00

Como ya deben saber quienes probaron el framework MVC de la muchachada de Microsoft, viene con un motor de ruteo y la posibilidad de usar urls sin extensión, lo cual las hace bastante amigables (por ejemplo: http://sitio/productos/ver/1). Sin embargo, esta última opción solo está disponible (al menos de forma nativa) solo en IIS 7, o sea Windows Server 2008. Para poder correr una aplicación ASP.Net MVC en IIS 6 es necesario que las urls tengan la extensión en la parte del controlador (o sea, algo de la forma http://sitio/productos.mvc/ver/1). La extensión más usada por el momento es mvc, y para que esto funcione, se debe la mapear en IIS con la aspnet_isapi.dll así es el framework el encargado de procesar la solicitud.

Cuando lo hice por primera vez, fui entusiasmado a correr la aplicación en el server y me encontré con un error 404, lo cual no podía ser porque la url era totalmente válida y el sitio estaba montado correctamente. Después de varias pruebas y naufragios por google, encontré que la forma de que funcione es desmarcando el check "Verificar que el archivo existe" en el diálogo de mapeo de la extensión mvc, para que el IIS no restringa las solicitudes solo a archivos existentes:

Hecho esto, el sitio funciona bien. Próximamente voy a tratar de usar urls sin extensión en IIS 6 mediante el agregado de un módulo de reescritura (al estilo mod_rewrite de apache), porque sinceramente este tipo de urls me atraen más que las que tienen extensión, por lo mismo que dije antes.

Scrum y XP desde las trincheras

2008-10-29T16:01:00.002-02:00

El título del post corresponde a un libro muy interesante sobre gestión ágil de proyectos. Si bien es un libro bastante corto, lo que lo hace interesante es que no se va por las ramas con mucha teoría de metodologías y demás yerbas sino que trata una serie de consejos prácticos de manera tal que el lector pueda comenzar a utilizar técnicas ágiles apenas leidos unos cuantos capítulos.

El libro se puede comprar impreso, o bien puede ser descargado de aquí
Quienes no estén muy familiarizados con el inglés, podrán encontrar una traducción (no la leí, así que no puede decir si es buena o no), aquí, y despues contarme qué le pareció el libro.

5 Estrellas Platinum

2008-10-23T13:59:00.004-02:00

Hace unos días salió a la luz la esperada 5ta estrella de Platino del programa de capacitación Desarrollador Cinco Estrellas.

Para alcanzarla se debe tener la 5ta estrella dorada y rendir al menos un curso más, entre dos disponibles: Linq y Silverlight 2.0. Como siempre, el material me parece bastante escaso, aunque hay que reconocer que para un desarrollador que ya llegó a esta instancia del curso, solo necesita una introducción para entender un tema y luego investigar por su cuenta para profundizar y lograr los conocimientos necesarios para utilizarlo en el trabajo diario.

ASP.Net MVC + System.Linq + Tipos Anonimos = Soluciones Elegantes

2008-10-03T14:40:00.005-03:00

Hace poco me encargaron el desarrollo de una pequeña aplicación web de uso interno, así que como era un proyecto de bajo riesgo y pocas líneas de código, aproveché para hacerlo con ASP.Net MVC, para aprenderlo y usarlo (ya hice varias aplicaciones con Monorail y necesitaba tener mas herramientas para comparar con el nuevo framework MVC de los muchachos de Microsoft).

Antes de abordar el tema que motivó este post, algunas consideraciones sobre ASP.Net MVC:

Es excelente el soporte de intellisense para la edición de vistas, lo que facilita mucho la curva de aprendizaje.
Me pareció atinado el uso de ActionResult como resultado de las acciones, ya que permite hacer mejores aserciones en los tests unitarios (recordemos que las acciones en MonoRail son void)
No me pareció tan buena la asociación entre las vistas y la master page. Esto dificulta un poco el uso eventual de ajax. No prové las extensiones que provee MvcContrib, que implementa un atributo Layout al modo Monorail, pero parece que ayuda.
Es fantástico el uso que le dan a los métodos de extensión, que permite agregar lo que necesitemos a los helpers predefinidos
También me pareció acertado el uso de Generics y de expresiones Lamda en algunos metodos de los helpers. Por ejemplo, al definir un form con el HtmlHelper, podemos hacer Html.Form(p => p.MiAccion() ). La gran ventaja de esto, además del intellisense, es la facilidad de refactoring, ya que estamos referenciando tipos y métodos de las clases y no cadenas de caracteres que no representan anda para el IDE ni para el compilador.

Un poco de magia

Volviendo al tema que da título al post, voy a contar qué tuve que hacer y como lo solucioné. Cuando ya tenía lista la aplicación, me pidieron que se pueda exportar a Excel el resultado de un par de reportes. Inmediatamente recordé como lo hacía con webforms, renderizando la grilla directamente al stream y cambiando un par de headers, pero cuando comencé a pensar como trasladarlo al patrón MVC las cosas se complicaron. Después de un rato en Google, encontré este excelente post que me salvó la vida (y le dio otro punto a favor a los ActionResult, ya que hace uso extensivo de la herencia sobre ese tipo).
Obviamente lo primero que hice fue bajarme el código, buscar las dos clases que necesito y agregarlas a mi proyecto. Luego de hacerlo, me puse a ver en más detalle el código y me enconté con que no me servía así como estaba, ya que usaba Linq to SQL y mi proyecto usa ActiveRecord, así que en vez de tener un IQueryable, tenía un IList. Aquí empieza a aparecer la magia, ya que simplemente agregando un using a System.Linq, me apareció el método de extensión AsQueryable() en la interfaz IList, así que pude pasar el parámetro que necesitaba. Hecho esto, tampoco me funcionaba, ya que la clase usaba el mapping de Linq to SQL para descubrir las propiedades o nombres de las columnas para armar la tabla en Excel. Solución rápida: el siempre querido Reflection para indagar las propiedades del tipo de dato guardado en el IList.
Listo, con eso la exportación funcionó bien, pero con un pequeño detalle. Aquellas propiedades que eran un tipo de dato complejo (una clase), se exportaban como el nombre del tipo y no el valor que yo quería. Por ejemplo, la entidad tenía una propiedad del tipo Usuario, y se exportaba como MiEspacioDeNombres.Usuario, en vez de exportar el nombre del usuario. Y acá aparece la potencia del framework 3.5 en todo su explendor, simplemente haciendo una consulta Linq sobre el IList y devolviendo objetos de tipo anónimo con las propiedades que quiero exportar ya resueltas:
var lista = from p in miListado select new { Propiedad1 = p.P1, Propiedad2 = p.P2, Usuario = p.Usuario.Nombre }

Esto es todo. Simplemente quedé asombrado por las posibilidades que brindan las nuevas características del lenguaje en el framework 3.5 para resolver de manera elegante cuestiones que surgen cuando ya se tiene la aplicación diseñada y no vale la pena hacer mucho refactoring.

Javascript, ASP.Net Ajax y arreglos clonados

2008-05-07T13:50:00.002-03:00

Para un desarrollo con ASP.Net Ajax necesitaba poder clonar un arreglo devuelto por un webservice (en realidad acabo de aprender que los arreglos en javascript son tipos por referencia). Fue así que después de algunos intentos de escribir una función, opté por buscar en Google y encontré esta opción:

Object.prototype.clone = function () {
var o = new Object();
for (var property in this) {
o[property] = typeof (this[property]) == 'object' ? this[property].clone() : this[property];
}
return o;
}
Array.prototype.clone = function () {
var a = new Array();
for (var property in this) {
a[property] = typeof (this[property]) == 'object' ? this[property].clone() : this[property];
}
return a;
}

Cuando la voy a probar, descubro que la clonación en profundidad (deep clone) la hace perfectamente, sin embargo, por alguna extraña razón que después de una mañana completa no logré comprender, no se lleva bien con los scripts que genera ASP.Net Ajax, y da un error bastante extraño y hace que dejen de funcionar algunas cosas de Ajax. Cosa e' Mandinga. Primero pensé que era un conflicto de nombres, así que le cambié el nombre "clone" por "clonar", y tampoco.
Resumiendo, como necesitaba avanzar con el desarrollo, hice un segundo intento con el amigo Google y encontré esta función acá: http://bytes.com/forum/thread715567.html

Funciona a la perfección, y no se lleva mal con ASP.Net Ajax. Es así el mágico mundo de la programación.

Programar para Web es facil

2008-04-18T16:20:00.002-03:00

A esta altura ya me da pena ver como algunos programadores jóvenes (entiéndase programadores que se están iniciando), desembocan la mayoría de las veces en soluciones muy complejas a problemas simples.

¿Por qué? Por supuesto que la respuesta no la tengo, pero quizás una aproximación, y es esta: el modelo de Webforms de ASP.Net hace complejo un protocolo simple (como lo es el HTTP).

Me explico un poco mejor. El principal objetivo "marketinero" de los webforms fue acercar a los programadores de aplicaciones de escritorio al desarrollo web. Para ello, dotaron a ASP.Net de un complejo ciclo de vida de las páginas, eventos y controles, todo para que los webforms se parezcan lo más posible a los winforms. Y lo que consiguieron es que gente que nunca programó en web comience a hacerlo, pero a hacerlo al estilo windorms. Es así como hoy vemos programadores Web que no saben como funciona HTTP, incluso algunos que no distinguen cuándo están corriendo en el servidor y cuándo en el cliente. Y ni hablemos del mal uso de la sesión, al punto de degradar la aplicación o hacer que los usuarios pierdan trabajo cuando actualizan una dll del stio.

Hace poco vino un compañero de trabajo a hacerme una pregunta extraña sobre la relación entre el esquema del documento HTML y los Themes de ASP.Net 2.0. Como la pregunta me dejó medio descolocado, empecé a indagar para saber cuál era el problema real. Y el problema real era que quería usar un botón que había programado alguien y aparentemente no se llevaba bien con los temas. Mi sugerencia entonces fue, que si ese botón no funcionaba, que ponga un link o un botón común, a lo que me respondió que no le servía porque tenía que cambiarle el texto del lado del servidor, porque en un momento servía como botón "Buscar" y en otro como botón "Volver". La primera solución que se me ocurrió fue simplemente usar dos páginas distintas, una con los filtros y otra con los resultados de la búsqueda. Y ahí fue donde me dí cuenta del título de este post: "Programar para la web es fácil, si se piensa en web".

Mis consejos para los nuevos programadores (y para los no tan nuevos) que quieran desarrollar aplicaciones basadas en la web son estos:
- Conocer como funciona el protocolo HTTP
- Saber que aunque los webforms no lo permitan se puede tener más de un tag "form" por página
- Saber que se puede trabajar con .Net para la web sin usar los odiosos webforms (estudiar por ejemplo MonoRail o ASP.Net MVC)
- Buscar siempre la solución más sencilla que funcione. Si algo no se puede resolver de una manera, tirarlo y buscar otra solución

Inyección de dependencia en Enterprise Library

2008-04-15T11:06:00.003-03:00

Según publicó InfoQ en este artículo, Microsoft implementó una librería para inversión de control e inyección de dependencia, que va a salir junto con la nueva versión de Enterprise Library.

Pareciera que los muchachos de P&P se están avivando de qué es realmente lo que se necesita a la hora de crear una aplicación con una buena arquitectura, y ya se copiaron (porque realmente es así) dos de los componentes del Castle Project, como ser MonoRail para el desarrollo web con MVC y Windsor/Microkernel para la inyección de dependencia. Lo que no termino de entender es cómo para algunas cosas van tan rápido (como las nuevas versiones del framework .net) y para otras van tan lento (recordemos que el proyecto Castle tiene ya un buen tiempito y está bastante maduro aunque no tenga un release formal).

Creo que ya no quedan dudas de que por la plata baila el mono.

5 Estrellas .Net

2007-12-17T21:56:00.000-03:00

Bueno, eso, que desde hace unos días tengo las 5 estrellas del programa Desarrollador 5 Estrellas. Para alcanzarla hay que rendir temas de Framework 2.0 y 3.0.

He aquí el diploma:

Libro

2007-11-14T19:32:00.000-03:00

Me había olvidado! Para los que aún no lo saben, ha salido a la calle un libro de mi autoría. Es una guía básica de introducción a la programación. Se abordan brevemente temas desde la resolución de problemas y algoritmos hasta UML, pasando por la programación estructurada y lógicamente Orientación a Objetos.

La imagen muestra la tapa. Como siempre, haciendo click podrán ampliarla. Sobre el logo de Visual Studio está mi nombre!

Primeras impresiones de ASP.Net MVC

2007-11-14T18:24:00.000-03:00

En estos días, Scott Gu publicó un breve tutorial sobre el nuevo framework de Microsoft para desarrollar aplicaciónes ASP.Net siguiendo el patrón MVC.

Como ya noté en mi anterior post sobre el tema, el parecido con MonoRail es realmente impresionante. No encontré un aspecto de la implementación de Microsoft que no esté ya soportado en MonoRail. Si se da la opuesta, hay varios detalles de MonoRail que aun no existen en ASP.Net MVC, como por ejemplo el SmartDispatcherController, aunque según Scott lo van a implementar antes de sacar el release del framework. Tampoco hay aun un soporte para Ajax.

Un aspecto en el que "se parecen mucho" (no quiero decir que el equipo de Scott haya copiado a los amigos del proyecto Castle, pero...) es la clase Html, que según se puede ver en el ejemplo, viene a cumplir el mismo objetivo que el HtmlHelper de MonoRail.

Hay algunas cosas que vi y no me gustaron. Una de ellas es la necesidad de especificar en la vista el tipo de datos del objeto que se va a usar para pasar información desde el controlador a la vista (lo que sería el PropertyBag de MonoRail). Obviamente esto da la ventaja del IntelliSense en las vistas, pero igualmente no me convence, creo que es más lo que se pierde que lo que se gana. Otro aspecto que no me gusta del todo es el hecho de poder usar WebControls en las vistas. ¿En qué baso mi postura? En que para interactuar con los WebControls hay que acudir al code behind de la página. Esto puede confundir un poco, haciendo el código menos legible, ya que al código del controlador y al de la vista, se agrega el del code behind. Además existe el riesgo de que un programador poco experimentado termine escribiendo lógica de la aplicación en los manejadores de eventos de los controles, rompiendo claramente el patrón.

Bueno, ¿como sigue esto? Seguiremos esperando la salida del framework para juzgarlo con más herramientas que un simple artículo.

MVC en ASP.Net

2007-10-17T19:42:00.000-03:00

Hace algunos días ScottGu publicó este post sobre el nuevo framework de MVC en ASP.Net. Por la imagen que se ve en el post, sigue una estructura muy similar a la de MonoRail, en cuanto a la organización de las carpetas. Todavía no se lo puede bajar para ir viéndolo en acción y tampoco vi los videos donde lo muestran, pero se me vienen algunos pensamientos a partir de la imagen del post:

Al parecer ya hay soporte para pruebas unitarias sobre los Controllers, veremos si es tan bueno como MonoRail (o mejor)
Me inquieta ver como relacionan el modelo de ejecución de los webforms, con sus postbacks y su ciclo de vida complejo con las acciones de los postbacks
Según un comentario que se ve por ahí, a traves de plugins se va a poder usar cualquiera de los engines de renderización de vistas implementados para MonoRail. Eso está bueno!

Seguiremos esperando y cuando se pueda hacer alguna pequeña aplicación, trataré de hacer una comparación con MonoRail

Separación de responsabilidades

2007-10-09T11:07:00.000-03:00

Hace unos años (unos cuantos), cuando comencé a programar, aún no se hablaba mucho y no había suficiente documentación ni experiencias sobre separación de responsabilidades a la hora de escribir el código, entonces en el mismo archivo teníamos la lógica para actualizar la interfaz, para validar reglas de negocios y para manipular los datos.

Con el tiempo, sobre todo ahora con el auge de los blogs, creo que ya se sabe que si se quiere lograr una base de código sólida, mantenible y bien estrucutrada, debemos separar por un lado los datos (que pueden estar en un SGBDR), la lógica de negocios, la lógica de actualización de la interfaz y la interfaz con el usuario propiamente dicha. Existen patrones y técnicas que colaboran en cada uno de estos aspectos, desde la separación en capas hasta el MVC o el MVP.

Sin embargo, aun hay gente que hace cosas horribles, sin analizar un solo instante las implicancias de lo que está escribiendo o quiere escribir. Por ejemplo, hoy vi algo que me dejó con la boca abierta, por decirlo de una manera. Me mostraron el código de un trigger en SQL Server, que se encargaba de generar código JavaScript en base a campos de alguna tabla y lo insertaba en otra, para luego tomarlo directamente en una interfaz ASP.Net. Es decir, lógica de interfaz almacenada en la base de datos.

Le pido a los programadores nuevos: nunca una urgencia debe atentar contra la calidad del código, recordemos que como programadores, el código fuente es el principal documento que tenemos, y que si lo hacemos bien, nos va a evitar más de un problema. Pensemos simplemente que pasa si alguien que nunca tocó esa aplicación, debe corregir un error en el código javascript. ¿Cuánto tiempo le puede insumir llegar hasta el trigger para encontrar el problema? Con suerte, unas cuantas horas, cuando debería haberlo encontrado a los pocos minutos si estuviese donde tiene que estar.

Regreso

2007-10-09T09:54:00.000-03:00

Después de un tiempo de inactividad, estoy tratando de volver a escribir un poco más y con mayor frecuencia. En este tiempo he estado trabajando y escribiendo sobre tecnlogías que si bien no son novedosas (particularmente MonoRail y todo el proyecto Castle), siempre es bueno compartir experiencias.

Así que aquí estaremos, tratando de aportar un granito más de arena a la gran montaña de confusión que es el mundo del desarrollo de aplicaciones de software.

Performancing en FireFox

2007-02-23T20:48:00.001-03:00

Cada día que pasa me gusta más Firefox. Hoy descubrí un addon que se llama Performancing. Este addon es simplemente un editor para postear en blogs. Qué es lo más interesante? pesa alrededor de 200 kb, se baja en segundos y se configura muy fácil. Acabo de bajarlo y en menos de un minuto ya lo tenía configurado para postear en Blogger.

Hay que reconocer que la gente que está trabajando alrededor de Firefox, está haciendo un trabajo espectacular.

Este post fue enviado con Performancing

ASP.Net Ajax ya es release

2007-01-24T09:05:00.000-03:00

Así lo anunció ayer Scott Gu' anunció el lanzamiento de la versión 1.0 de ASP.Net Ajax, junto con la correspondiente versión 1.0 de ASP.Net Ajax Toolkit, que incorporó tres controles interesantes: un textbox con calendario (esto se podía simular con las betas y el RC usando el PupUpExtender, pero había que poner algunas líneas de código), un control tipo TabStrip a puro javascript y un MaskEdit para restringir el ingreso de datos, para alegría de los programadores de la vieja escuela (leáse de Clipper, Fox y demás).

Como siempre, la página oficial de ASP.Net Ajax está acá.
El post de Scott con el anuncio, lo pueden encontrar acá

El tamaño sí importa

2007-01-18T08:59:00.000-03:00

Cada vez que tengo que mantener código de otro, o ayudar a alguien con algún fuente, insisto en lo mismo: escribir métodos pequeños. Me he encontrado con métodos de más de 2000 líneas. En este post en Object Mentor, se comentan algunas de las razones por las que el tamaño de las clases y métodos sí importa, junto con las implicancias que tiene el código demasiado largo.

Separación de UI y Logica en Ajax

2006-10-23T08:27:00.000-03:00

Algo que ya muchos criticaron sobre Ajax (en particular sobre Ajax Library, o sea ATLAS) es que implica un uso bastante intensivo de JavaScript del innerHTML para actualizar la UI luego de llamar a WebServices desde el lado del cliente.

En respuesta a eso, Scott Gu escribió este excelente post con una propuesta de solución que me pareció muy buena. Sin embargo, despues de bajarme el codigo y darle una mirada, veo que hace uso de Reflection para pasarle datos al control que usa para renderizar la vista. Todos sabemos que Reflection es una gran herramienta, pero puede tener algunos problemas de redimiento y que deberíamos evitarlo siempre que sea posible. Y en este caso es posible.

Mi solución es la siguiente. Por un lado, definir una interfaz que exponga una propiedad para pasarle los datos al control:

public interface IDataView
{
object Data { get; set; }
}

Luego, cada control que querramos renderizar desde el ViewManager, deberá implementar la interfaz IDataView:

public partial class App_Views_Customers : System.Web.UI.UserControl, IDataView
{
protected void Page_Load(object sender, EventArgs e)
{
Repeater1.DataSource = Data;
Repeater1.DataBind();
}

private object data;
public object Data
{
get { return data; }
set { data = value; }
}
}

Por último modifiqué la clase ViewManager para que no use Reflection sino que requiera que el control sea también un IDataView:

public class ViewManager
{
public static string RenderView(string path)
{
return RenderView(path, null);
}

public static string RenderView(string path, object data)
{
Page pageHolder = new Page();
UserControl viewControl = (UserControl) pageHolder.LoadControl(path);

SetData(viewControl as IDataView, data);

pageHolder.Controls.Add(viewControl);
StringWriter output = new StringWriter();
HttpContext.Current.Server.Execute(pageHolder, output, false);

return output.ToString();
}

private static void SetData(IDataView view, object data)
{
view.Data = data;
}

}

Con esto, no solo eliminamos el uso de Reflection sino que el código quedó más claro, más OO y al no acceder a un campo por su nombre como variable, quedó más seguro ya que permite verificar todo en tiempo de compilación.

Artículo sobre ATLAS

2006-10-05T20:51:00.000-03:00

Hoy vio la luz el número de octubre de Level Extreme, que en esta oportunidad incluye un artículo mío sobre ASP.Net Ajax Library, es decir, ATLAS.

Fue muy interesante escribir este artículo porque si bien ya hace un buen tiempo que vengo experimentando con ATLAS, solamente había usado los controles del lado del servidor (principalmente el UpdatePanel), y para poder profundizar un poco en el tema, tuve que hacer unas pruebas con web services y realmente me pareció muy cómodo y sencillo de usar.

Variables static en VB.Net

2006-10-04T14:32:00.000-03:00

Hoy me hicieron la siguiente pregunta: "¿Que diferencia hay en Visual Basic .Net entre shared y static?". Como soy un programador de C# y no de ese otro lenguaje feo atiné a responder que static es lo mismo que shared, pero en C#. Pero como mi interlocutor no quedó muy satisfecho con la respuesta, tras unos minutos de lectura me vengo a enterar que en VB.Net, una variable local a un método puede tener el modificador static, lo que hace que mantenga el valor entre llamadas. Es decir, si tenemos algo así:

Public Sub Metodo1()
Static Dim contador as Integer
contador = contador + 1
Console.WriteLine(contador)
End Sub

Public Sub Metodo2()
Metodo1()
Metodo1()
End Sub

Como resultado, tendremos en la consola los valores 1 y 2, ya que la variable "contador" mantiene su valor entre una y otra llamada al método.

Ahora bien, ¿de que sirve esto en un leguaje orientado a objetos? La misma funcionalidad se puede resolver perfectamente con el uso de un atributo privado de la clase: (lo escribo en C# porque ya fue suficiente VB.Net por hoy)

private int contador;
public void Metodo1()
{
Console.WriteLine(++contador);
}
public void Metodo2()
{
Metodo1();
Metodo1();
}

Obviamente, C# que es un leguaje bien hecho, no tiene un equivalente al static de VB.Net. Esto no hace más que reafirmar mi idea de que VB.Net es un leguaje feo, que arrastra todos los problemas de diseño de un lenguaje de programación desde sus primeras versiones y que permite escribir código muy mal estructurado (y que los programadores de VB.Net de alguna manera u otra se las arreglan para usar todas las cosas de VB.Net que no deberían usar para que el código quede bien escrito).

Estimar tiempos no es como jugar al golf

2006-09-29T15:09:00.000-03:00

Hace unos días empecé a leer Extreme Programming for Web Projects, un librito bastante entretenido y de lecutra liviana que, como su título lo indica trata de como enfrentar proyectos de desarrollo de aplicaciones web siguiendo técnicas de desarrollo ágil.

A grandes rasgos, los temas tratados no difieren en absoluto a los de cualquier libro/articulo/sitio web sobre metodologías ágiles, salvo por los capítulos donde los autores abordan temas relacionados con las particularidades del desarrollo web, como los son el diseño gráfico de la aplicación y el uso de XML.

Hay un capítulo en el que se hace una analogía entre la estimación de tiempos y un juego de golf y quería comentarla porque me pareció interesante el planteo (aunque no sea más que otra forma de plantear el problema que todos conocemos). Parafraseando (y traduciendo) a los autores, pensemos en el desarrollo de software como un juego de golf en el que tenemos un objetivo (el hoyo), pero está bastante lejos y no podemos verlo. Nuestro cliente puede decirnos que el hoyo está a 130 metros de donde estamos, y al centro de un dogleg. Los miembros del equipo ya han jugado al golf antes y nos advierten que en el medio podría haber obstáculos, como lagunas o tramas de arena. Entonces, ¿qué tan fuerte le pegamos a la pelotita?, ¿el viento puede influir?, ¿el cliente realmente sabe donde está el hoyo?, ¿nuestro compañeros de equipo no sabían de un obstaculo que estaba en medio? ¿eh?

ATLAS será release en diciembre

2006-09-12T13:14:00.000-03:00

Así es, finalmente el framework ATLAS verá la luz como un producto con soporte y todo a fines de este año, bajo el nombre de "Microsoft AJAX Library" y el ATLAS Control Toolkit será bautizado formalmente como ASP.Net AJAX Control Toolkit.

Más información en el blog de Scott Guthrie

Otro artículo de Mocks

2006-09-12T08:30:00.000-03:00

Ayer salió el nuevo número de LevelExtreme donde salió publicado otro artículo mío, esta vez sobre pruebas de interacción con mock objects.

Como podrán ver en el artículo, la idea es parecida a la de otros artículos sobre mocks, pero esta vez, lo que se debe probar es que la aplicación reacciona bien ante los datos enviados por una balanza electrónica de camiones y aplica correctamente las reglas de negocios.

Despues de leer el artículo (y dejar algún comentarió acá), los inviton a que le den una mirada al blog del autor de los Rhino Mocks (www.ayende.com/Blog), qué está haciendo un excelente trabajo, en especial con la librería RhinoCommons (que dicho sea de paso, ya recibió algunos aportes míos).

Ayudando al asistente

2006-08-29T20:12:00.000-03:00

En mi primer artículo en Level Extreme, expliqué un poco por arriba como escribir clases de negocios para aprovechar al máximo el ObjectDataSource de ASP.Net 2.0.

En una parte del artículo, explico que en el asistente para configurar el data source, hay que desmarcar el checkbox que dice "Show only data components" para que aparezca nuestra clase. El problema de eso es que en el combo van a aparecer todas las clases que Visual Studio puede encontrar en la solución, lo cual, en un proyecto grande puede ser bastante molesto, ya que debemos encontrar la clase que buscamos entre muchas (muchas!) clases.

Lo que me faltó poner en el artículo es que si agregamos el atributo DataObject a la clase, ésta va a aparecer en el combo cuando esté marcado el combo de "Show only data components", con lo cual achicamos un poco la lista. Es más, si agregamos el atributo DataObjectMethod a los típicos métodos CRUD, el asistente los va a mostrar cuando tengamos que elegir los métodos para seleccionar, insertar, actualizar y borrar entidades. Toda una pinturita.

La clase entonces quedaría más o menos así:

[DataObject(true)]
public class OrderController
{
[DataObjectMethod(DataObjectMethodType.Select,true)]
public ICollection GetAll()
{ ... }
}

El atributo DataObjectMethod tiene una propiedad de tipo DataObjectMethodType, que es un enumerado de: Select, Fill, Update, Insert y Delete, para indicar cada uno de los métodos CRUD.
Tambien tiene un atributo para indicar si es el método por defecto. Si está en true, ya aparecerá seleccionado en el combo del asistente.

Peticion de cambio de nombre de .Net 3.0 a WinFX

2006-08-24T21:07:00.000-03:00

Como muchos saben, hace tiempo que Microsoft viene trabajando en lo que será la API para Windows Vista, inicialmente llamada WinFX. Como toda API, WinFX consiste de un serie de herramientas y librerías para acceder a los servicios del sistema operativo desde nuestros desarrollos, pero a diferencia de cualquier API de los Windows anteriores, WinFX será totalmente orientada a objetos y accedible directamente desde .Net.

Recientemente, se anunció que WinFX cambia de nombre a .Net 3.0. El cambio de nombre no fue tomado para nada bien por la comunidad internacional de desarrolladores. El principal motivo del disgusto es porque WinFX no representa el siguiente paso de .Net (lo que sería el sucesor de .Net 2.0), sino que es una API. No es una plataforma de desarrollo, como sí lo es .Net. Muchos argumentan (y con razón), que el nombre .Net 3.0 va a generar mucha confusión, sobre todo en los recién llegados a la plataforma. Además, el cambio de nombre se hizo de manera arbitraria y sin consultar a la comunidad.

Es por ello que se lanzó una petición online para que el nombre de .Net 3.0 sea revertido a WinFX. Quienes quieran colaborar con el cambio de nombre y apoyen la idea de que .Net es una cosa y WinFX es otra, pueden dejar su firma acá (http://www.petitiononline.com/winfx/petition.html).

Quienes quieran conocer un poco de WinFX, pueden dirigirse al home site de Windows Vista, en particular a este artículo: http://msdn.microsoft.com/windowsvista/default.aspx?pull=/library/en-us/dndotnet/html/intronetfx30.asp

Inauguración con Reconocimiento

2006-08-21T16:49:00.000-03:00

Hoy 21 de agosto, inauguro el nuevo blog. ¿por qué uno nuevo si ya tengo el de MSN Spaces? Bueno, porque ya no me gusta mucho el camino que está tomando MSN, y la verdad que Blogger.com parece un mejor servidor para esta actividad.

Para inaugurar, les cuento que hace un par de semanas Microsoft me envió un diploma de reconocimiento por mi colaboración como instructor en el programa "Desarrollador 5 Estrellas"

He aquí la foto del diploma.

A propósito, ya pueden capacitarse en la tecnología .Net en el nuevo DCE 2005