sábado, 22 de octubre de 2011

ASP.NET MVC (II) Ventajas


Vamos a continuar con esta serie de posts sobre ASP.NET MVC. Puedes ir también a los artículos 1 y 3.

¿Qué ventajas nos ofrece este modelo MVC en ASP.NET?
  • Es extensible
  • Es amigable con SEO (las url son muy sencillas, e implementan las acciones y parámetros de forma natural, facilitando su acceso mediante buscadores) y REST
  • Nos da un enorme control sobre la salida
  • Nos da un enorme control sobre el flujo
  • Nos separa de forma natural las responsabilidades
  • Facilita la prueba de nuestras aplicaciones de formas que en el mundo WebForms no podríamos ni imaginar.
  • Se sigue basando en todo el framework existente ASP.Net (masterpages, membership, etc.)
  • Se integra con el funcionamiento natural de la web, sin metáforas que nos acaben complicando la vida en cuanto tratamos de realizar cosas más complejas
  • Estabilidad y fiabilidad: se basa sobre el más que probado framework asp.Net, e integra casi cualquier elemento que nos pueda hacer falta
  • Facilita los cambios (sí, esta vez de verdad, de forma muy superior a como se facilita en las aplicaciones N-tier)
  • Facilita separar el trabajo de los diseñadores, que pueden editar directamente la capa de presentación, sin tener que pasar como ocurre con Silverlight con herramientas específicas de diseño.
  • Se integra de forma natural con jQuery
¿Debemos migrar las aplicaciones Webform existentes?
No. Para nada. En todo caso, habría que evaluar si los problemas y cambios que nos solicitan en el mantenimiento de las aplicaciones antiguas, nos justifican el cambio.
Lo que sí es cierto, es que la migración a MVC ofrece de forma exponencial unos enormes beneficios de cara al mantenimiento.

viernes, 14 de octubre de 2011

Así no se puede trabajar

Esto no es serio. Así no se puede trabajar. Hoy traigo un mensaje (cuadro de diálogo) de Microsoft Powerpoint, que me ha hecho desear asesinar a alguien. Esto no está sacado de ningún sitio web, ni na. Lo he sufrido en mis carnes. Aún sigo sin saber el motivo ni la información perdida. El mensaje es:


Para los que no estéis puestos en inglés, os traduzco lo que pone tal y como lo he sentido:
  • Powerpoint ha encontrado contenido en este fichero, que no entiende.
  • Por tanto, Powerpoint ha decidido borrar este contenido, y no se puede recuperar. Ole, ole y ole tus...pues eso.
  • Te interesaría revisar esta presentación POR SI ACASO detectas algo cambiado o borrado
Pero si no es mía la presentación! Pero qué narices me está contando! Pero cómo voy a saber si algo falta o no! Y ni siquiera puedo contactar con su autor!!!!!

Queridos desarrolladores de Microsoft Powerpoint: GRACIAS. Gracias por hacerme sentir idiota. Gracias por dejarme alucinado con mensajes tan retorcidamente creativos.
En fin, que así no se puede trabajar.

jueves, 13 de octubre de 2011

Chuck Norris Exception

He encontrado en este link esta pequeña perla (aunque me suena, quizás sea vieja):


Instalación

$ npm install ChuckNorrisException

Uso

var ChuckNorrisException = require('ChuckNorrisException');

var imFeelingLucky = true;
try {
  if (imFeelingLucky) throw new ChuckNorrisException();
} catch (e) {
  // FAIL: You cannot catch a ChuckNorrisException
}

Si intenta lanzar una ChuckNorrisException resultará en un fallo y se cerrará su programa.
¿El motivo? Porque usted no lanza a Chuck Norris....Chuck Norris le lanza a Usted!!!
Los siguientes errores se producirán si se intenta tamaña estupidez.

  • Usted no lanza a Chuck Norris....Chuck Norris le lanza a Usted!!!
  • Chuck Norris escribió "Hola Mundo" una vez...y se llamó Unix.
  • Chuck Norris le pateará el culo asíncronamente
Original: http://criso.github.com/ChuckNorrisException/

Lloremos una gran pérdida


Bueno, hoy 13 de Octubre, hemos de llorar una gran pérdida para el mundo del desarrollo de software. Su contribución ha sido incalculable, ya que ha influido en muchísimos aspectos técnicos que aún están en boga hoy en día, tantísimos años después.

NO, no me refiero a Steve Jobs (también, recientemente fallecido, y contra el que nada tengo).

Me refiero a Dennis Ritchie, autor que ha influido en más de una generación de universitarios (no sólo informáticos), a través de su casi obligatorio título "El lenguaje de programación C" de Kernigan & Ritchie. Algún otro título suyo, también resultó de lectura obligatoria en la universidad, como aquel sobre Unix, ya que por otra parte, este señor fue COAUTOR del sistema UNIX. Sí, sí, el que aún se sigue venerando como fuente de Linux y otros dialectos.

Descanse en Paz

miércoles, 12 de octubre de 2011

Novedades en el ASP.Net Framework 4.0


No sólo de MVC vive el hombre, así que antes de que llegue la siguiente versión de Visual Studio y otro nuevo Framework, vamos a repasar algunas de las novedades que llegaron en la última versión del .Net Framework 4.0 para ASP.Net.

  • Nuevas propiedades en controles para mejorar la gestión del ViewState. Ya no sólo se gestiona a través de la  propiedad [EnableViewState].
  • Mejoras en la cache: opción de compresión en las caché "Out-Of-Process" y nuevas opciones de customización de caché mediante la creación de custom providers. Esto puede ser especialmente útil en entornos con poca memoria.
  • Nuevas opciones para renderizar el código html mediante las buenas prácticas de accesibilidad recomendadas, evitando tablas, estilos inline, etc. Para ello, los controles existentes (como el control menu), han incorporado nuevas opciones de renderizado. Entre otras, la propiedad [IncludeStyleBlock] (true/false), ahora permite habilitar o inhabilitar la inclusión del bloque de estilos inline, tal y como se hacía en el framework 3.5.
  • Nuevas opciones para facilitar y automatizar el nombrado de elementos HTML (los IDs), que hasta la versión del framework 3.5 eran prácticamente imposibles de predecir. Es decir, el framework los nombraba de forma que no facilitaba la inclusión de código Javascript, ya que éste necesita predecir los nombres de los elementos HTML a los que se quiere acceder.
  • Validación de peticiones extensible. En el framework 4.0 se validan todas las peticiones, aunque es posible configurar el comportamiento y extender el comportamiento mediante validación de cabeceras, URL, parámetros, etc.
  • AJAX: soporte para jQuery de serie de Microsoft, soporte para plantillas de lado cliente.
  • Disminución del tamaño de los web.config
  • Query Extenders
  • Expresiones HTML nuevas para codificación: <%: %>
  • RedirectPermanent
  • Despliegue automatizado de aplicaciones Web con transformación de configuraciones.
Este post es de resumen, desde luego que lo que tocaría es ahora ir tocando todos y cada uno de estos temas. Algunos, como el nuevo soporte de jQuery, son apasionantes. A ver si le puedo sacar algún ratito y podemos detallar si no todo, alguno de ellos. De todas formas, antes me gustaría irme quitando también la serie de posts sobre MVC. En fin: pasito a pasito.

lunes, 10 de octubre de 2011

El framework CLSA .Net

Lleva ya mucho tiempo esto del CLSA dando vueltas por el mercado.

¿Que cómo lo descubrí? Yo andaba buscando material para frameworks que nos ayudasen a mejorar la metodología de desarrollo en mi empresa actual. El hecho de tener CMMI nivel 3 está muy bien, pero si no das a los equipos de desarrollo formas de trabajar "reales", al final corres el riesgo de convertirte en un teórico de la tecnología.

El caso es que mientras buscaba frameworks de pruebas y modelos de negocio, me encuentro una referencia a CLSA y el señor Rockford Lhotka.

Lhotka es autor de varios libros sobre desarrollo .Net, y autor del framework CLSA que está orientado al desarrollo rápido de aplicaciones. CLSA es un framework que facilita la construcción de la capa lógica de negocios para aplicaciones Windows, Web, orientadas a servicios, y de flujos de trabajo.

CLSA.Net simplifica y estandariza la creación de capas de negocio en .net

La implementación de CLSA para .Net comenzó en 1999, y sigue evolucionando todavía hoy con soporte para Visual Studio 2010, Microsoft .NET 4.0, Silverlight 4, y Windows Phone 7.

¿Porqué la desestimé? En su momento, estuve evaluando la capacidad de este framework para su uso e integración con nuestra metodología .Net, pero me pareció demasiado "customized". Efectivamente promete flexibilidad, pero a costa de hacer el desarrollo muy dependiente de este framework. En absoluto me pareció poco potente ni le encontré fallos significativos en el tiempo que le dediqué, así que os animo a los que estáis evaluando frameworks de este tipo a que le déis una oportunidad.

Esto acaba aquí. Si esperas que te detalle información sobre el uso de este framework sin haber tenido yo experiencia personal real, estás listo. Para eso ya tienes otros blogs. Cuidaros.

sábado, 8 de octubre de 2011

ASP.NET MVC (I) Introducción

Introducción
Hoy vamos a ver una introducción a lo que espero sea una larga serie de artículos sobre ASP.NET MVC.
Podéis saltar directamente a las partes 2 y 3
Aquellos que vengáis del mundo Java prácticamente veréis a MVC como un estándar del día a día. Pero en el mundo .Net, no es así.

El problema es que en .Net hemos sufrido de la obsesiva directriz de Microsoft en el sentido de OCULTAR la complejidad y la esencia de las cosas, encapsulándolo todo en nuevas metáforas supuestamente más sencillas. Eso ha funcionado muy bien, consiguiendo en el modelo ASP.NET Webforms una forma relativamente simple de construir aplicaciones Web. Pero no deja de ser una abstracción, una metáfora. Cuando intentamos bajar al nivel del código Javascript es cuando realmente vemos que la metáfora de los WebForms se cae con su propio peso y nos ha estado ocultando una realidad compleja, pero que en otras tecnologías como Java, se maneja de forma natural.

Desde hace ya algún tiempo, ASP.NET MVC se ha introducido como una forma de volver a las raíces, de resolver las dos principales problemáticas que existían en los desarrollos web:
  • No ocultar la naturaleza de la web mediante falsas metáforas, que realmente nos complicaban mucho más la vida, como el uso de ViewState, etc.
  • Los flujos de las aplicaciones no están integrados de forma natural en las estructuras y arquitecturas de los webforms. Los webforms están diseñados para ser sencillos de implementar desde el punto de vista de los WinForms (pantallas de escritorio). Pero no constituyen una forma natural de implementar y separar la visualización de los datos, de lo que es el negocio.
El modelo MVC ante todo se basa en la estructura del flujo de nuestra aplicación Web. Representa de forma natural una vista por pantalla (o tipo de pantalla), e implementa acciones que no son sino las acciones de nuestras pantallas.

¿Cómo funciona MVC?
El patrón que se usa en MVC de ASP.NET es el de Front Controller.
Al controlador le llegan peticiones, que pasan por un mecanismo de enrutamiento. El enrutador decide qué controlador debe dispararse, ese controlador es el que da paso a las acciones e interactúa con el modelo, dando como resultado una vista.

El enrutamiento se encuentra dentro del espacio de nombres System.Web.Routing. Se trata de un espacio de nombres independiente de ASP.NET MVC, por lo que las personas que utilicen ASP.NET clásico (el de webforms), pueden tener también acceso a ese espacio de nombres.

Enrutado
La esencia de MVC dentro de ASP.NET se encuentra en el enrutado. Para ello, en el archivo Global.asax se define una tabla de rutas, una colección de rutas (RouteTable). Esa tabla lleva una ordenación, y el comportamiento vendrá definido por dicho orden (debe de ponerse el comportamiento más restrictivo siempre antes). Además, este enrutado permite restricciones (por ejemplo, en función de una clase específica definida por nosotros, o bien a través de expresiones globales).

Definición de rutas
La definición de rutas se hace mediante patrones. El patrón más común es:
{Controlador}/{acción}{parámetro}
Esto hace que la forma más habitual de navegar en una aplicación MVC sea mediante url's del estilo:
http://misitioweb/controlador/accion/parametro

Para definir una ruta por código sería algo así como:
var route = new Route("{controller}/{action}/{param}",new MvcRouteHandler());
class Route: RouteBase{
     //definición de la ruta
     string Url
     RouteValueDictionary Defaults //valores por defecto
     RouteValueDictionary Constraints //permite definir restricciones
     RouteValueDictionary DataTokens //permite asignar metadatos donde guardar información adicional 
     IRouteHandler RouteHandler
}

Bueno, ya vale para una primera introducción.
Para saltar a la segunda parte de este post, clic aquí.

jueves, 6 de octubre de 2011

Refactoritis


Hoy vamos a tratar una enfermidad muy común de los programadores "experimentados": La Refactoritis.

La refactorización se lleva haciendo durante décadas. No es algo nuevo, a pesar de que siempre se cite al bueno de Martin Fowler como referencia, en su libro "Refactoring: Improving the Design of Existing Code". Si no conocéis a Martin Fowler y os dedicáis a la informática, no sé a qué esperáis para leer este libro y saber un poco más de este autor.

La refactorización se define en la Wikipedia como "técnica de la ingeniería del software para reestructurar un código fuente, alterando su estructura interna sin cambiar su comportamiento externo". Es en estos momentos cuando muchos de vosotros estaréis asintiendo con la cabeza y pensando en frases como "pues yo refactorizo mucho o poco", "yo no lo veo una enfermedad", etc, etc.

¿Y qué sería en ese caso la Refactoritis? Pues la podríamos definir como el "trastorno compulsivo que deriva en el uso excesivo de la refactorización del código". Vamos, cuando se le va la mano al programador y no para hasta que ha llegado al final del código, y lo ha dejado todo "a su gusto".

Como hemos visto antes, la refactorización no cambia la funcionalidad. Es decir, no se aporta valor al producto desde el punto de vista de los requisitos. En la metodología SCRUM, estaríamos dedicando horas de trabajo sin implementar ninguna "historia de usuario". En realidad, sería una forma de procrastinación: no hacemos algo que se haya solicitado, sino que estamos haciendo algo que nos gusta o nos parece subjetivamente agradable o necesario. Por supuesto que habrá ocasiones en que sí se ha creado una tarea a realizar de refactorización, pero en esos casos nos deberíamos preguntar si realmente no deberíamos atajar la causa del problema: no generamos código de calidad según estándares, lo que obliga a refactorizar después.

La refactoritis deriva en múltiples problemas. Veamos primero las necesidades que nos pueden llevar a refactorizar el código, y vamos a discutirlas una a una:
  • Calidad. Esta suele ser una de las excusas más usadas. Estamos creando calidad, mejorando la calidad. Y como no sabemos medir la calidad, no hay límite para nuestras ansias de refactorizar. Podemos seguir refactorizando hasta que nuestra sensación subjetiva de calidad consuma el tiempo de desarrollo. Algunos autores defienden que el código de calidad es bueno, y que mientras se satisfagan las pruebas unitarias, no pasa nada. El problema, es que las pruebas unitarias no son perfectas, lo que puede derivar en que a pesar de que "todo parece ir bien" tras refactorizar, en realidad estamos introduciendo bugs en el código.
  • Mala planificación. En ocasiones, se planifica en exceso. Los programadores cuando se encuentran con que han terminado una tarea antes de la fecha planificada pueden hacer varias cosas. O buscan una nueva tarea, o tratan de llenar el tiempo de la tarea terminada. ¿Cómo? Pues refactorizando: mejorando comentarios, encapsulando, quitando código duplicado, etc.
  • Eficiencia. Supuestamente, un código refactorizado es más eficiente. Además, se supone que se entiende mejor y es más claro. Esto último es muy dudoso, ya que es muy fácil refactorizar código y dejarlo de forma que sea muy compleja de entender. En este caso, si no medimos la eficiencia, ocurriría lo mismo que con la calidad. Podemos pegarnos la vida intentando ser más eficientes, que como no se mide esa mejora en eficiencia...no hay límites a nuestra refactoritis.
  • Evolución. A veces, cambios en las normas de programación, en requisitos de calidad, etc., hacen que debamos refactorizar el código para que se cumplan las nuevas normas. Debemos recordar que salvo excepciones, el cliente paga por funcionalidades, no por la refactorización del código. Si no tenemos claras nuestras normas de desarrollo...mal asunto.
  • Evitar la reescritura de código. Es muy discutible que un código refactorizado sea mejor que un código reescrito. Deben establecerse las necesidades, y evaluar qué solución merece la pena en uno y otro caso. Si refactorizar es la alternativa a la reescritura de código, en realidad tenemos un problema mayor: el mero hecho de plantearnos reescribir el código significa que un tiempo invertido en el desarrollo "va a la basura". Los paños calientes y las vendas no van a ocultar que tenemos un problema mayor.
¿Cuáles son las prácticas que deberíamos aplicar?
  • No tocar el código que no se ha solicitado tocar.
  • No tocar el código para el que no se han definido pruebas (automatizadas o no).
  • No tocar el código sin antes realizar un análisis del coste (horas necesarias) para su refactorización, y definirlo como una tarea. Sólo así podremos controlar el tiempo necesario en rehacer las cosas una y otra vez. No deberíamos dedicar más horas de las estimadas a refactorizar, ni tocar más código del inicialmente identificado. Si no conocemos el alcance de nuestras acciones, no sabemos hacia dónde vamos.
  • El código se debe refactorizar ANTES de pasar las pruebas, en la actividad de verificación. Las pruebas son muy costosas (incluso automatizadas), por lo que deberíamos pensar dos veces antes de tocar un código que ha pasado ya las pruebas.
  • No tocar el código que afecte a otros desarrollos (en curso o en producción), sin antes hacer una evaluación del impacto y recibir la aprobación correspondiente. En muchas ocasiones, algo que funciona correctamente según las pruebas unitarias, al subirlo a producción ROMPE OTROS DESARROLLOS con los que interactuaba.

martes, 4 de octubre de 2011

Gestión de equipos: la teoría del caballo muerto

Hoy, a falta de algo más elaborado, tengo que echar mano de otro guiño de humor.

Para los que trabajáis en este mundillo del desarrollo de software, os arrancará algunaque otra sonrisa. Para los gestores de equipos y de proyectos que no lo hayáis entendido...manteneos alejados de mí.

Por cierto, haciendo clic en la imagen la veréis "en grande", ¿ok? pues ale.. a disfrutar

lunes, 3 de octubre de 2011

El gerente del turno de noche

A continuación, adjunto una imagen, que vale por cien palabras. Yo suelo decir una frase sobre los malos gestores y jefes de proyecto que reza que "mantienen los recursos lejos de los objetivos".

Vendría a ser similar esta iniciativa, en la que nuestro gerente favorito se encarga de poner los medios más inadecuados para las necesidades del proyecto.

Que aproveche.