miércoles, marzo 18, 2009

ASP.NET MVC 1.0

Después de que la versión final del ASP.NET MVC 1.0 no fue liberada a finales de Febrero como se había mencionado, no era un secreto que iba a ser liberada en el Mix09, y así fue.

Ya se puede descargar la versión 1.0 del ASP.NET MVC.

Ademas aquí hay una lista de aplicaciones de ejemplo.

Y en caso de que alguien se lo hubiera perdido, aquí se puede descargar todo un capitulo del libro "Professional ASP.NET MVC 1.0", donde explica como crear el sitio nerddinner.com


martes, marzo 10, 2009

Comparación del ciclo de vida de una página ASP.NET Webforms y ASP.NET MVC

El ciclo de vida de una página de una aplicación ASP.NET Webforms

  1. Page.OnPreInit
  2. MasterPageControl.OnInit (for each control on the master page)
  3. Control.OnInit (for each contol on the page)
  4. MasterPage.OnInit
  5. Page.OnInit
  6. Page.OnInitComplete
  7. Page.OnPreLoad
  8. Page.OnLoad
  9. MasterPage.OnLoad
  10. MasterPageControl.OnLoad (for each control on the master page)
  11. Control.OnLoad (for each contol on the page)
  12. Page.OnXXX (control event)
  13. MasterPage.OnBubbleEvent
  14. Page.OnBubbleEvent
  15. Page.OnLoadComplete
  16. Page.OnPreRender
  17. MasterPage.OnPreRender
  18. MasterPageControl.OnPreRender (for each control on the master page)
  19. Control.OnPreRender (for each contol on the page)
  20. Page.OnPreRenderComplete
  21. MasterPageControl.SaveControlState (for each control on the master page)
  22. Control.SaveControlState (for each contol on the page)
  23. Page.SaveViewState
  24. Page.SavePageStateToPersistenceMedium
  25. Page.OnSaveStateComplete
  26. MasterPageControl.OnUnload (for each control on the master page)
  27. Control.OnUnload (for each contol on the page)
  28. MasterPage.OnUnload
  29. Page.OnUnload

Ciclo de vida de una página de una aplicación ASP.NET MVC

  1. La tabla de routeo es creada
  2. El UrlRoutingModule intercepta la solicitud
  3. Se ejecuta el MvcHandler
  4. Se ejecuta el Controller
  5. El método RenderView es ejecutado

Más información
ASP.NET Page Events Lifecycle
Stackoverflow
Stephen Walther blog

lunes, marzo 09, 2009

Video y fotos del Web 2.0 CoffeCamp TJ

Gracias a @gabo que publico el video y algunas fotos del Web 2.0 CoffeCamp TJ en la página de la Comunidad Tijuana.NET.


También en la página del evento en Facebook se están agregando los recursos del evento.

También @ilescasp ha publicado en si Facebook algunas fotos que tomó.


¿Que podcasts escuchas?

Hoy en día es mas común el uso de medios independientes como podcast en lugar de los medios tradicionales como la radio.

Parte de esto es que generalmente un podcast se enfoca únicamente sobre un área o tema en particular, por lo tanto es muy sencillo el subscribirse a un podcast con contenido que realmente nos interesa.

Existen podcast de ocio, noticias, música, y áreas de especialidad como:

  • Diseño gráfico
  • Fotografía
  • Desarrollo de aplicaciones
  • y otras mas

Los podcast ademas ofrecen la versatilidad de poder descargar se al computador e inclusive a nuestro teléfono móvil, para así escucharlo cuando deseemos.

En mi caso en particular principalmente los podcasts que escucho están relacionados con desarrollo de software. La imagen al inicio del post es mi iTunes de la sección de podcasts, ¿Y ustedes que podcasts escuchan o recomiendan?


domingo, marzo 08, 2009

Web 2.0 CoffeCamp Tj


El pasado sábado 7 de Marzo, se llevo a cabo el primer Web 2.0 CoffeCamp en el D'Volada Café de Plaza Dorada en Otay, lugar del cual literalmente nos apoderamos por un espacio de poco mas de 2 horas.

Al evento asistieron @gabo, @webcool, @ilescasp, @agamenong, @bitfon, @mariohcornejo, @fcastellanos, @jesus_chavez, Carlos Hurtado, Jessica y @mario_chavez, ademas en linea creo que llego un punto en donde había como 10 personas mas, de los que recuerdo @stanmx, @angelnyo, ryozero y velocitj.

El inicio se retardo un poco por "problemas técnicos", el Internet en el lugar no funcionaba muy bien que digamos y la idea era transmitir el evento en vivo, ademas de la grabación de audio y video. Afortunadamente @bitfon nos presto un modem/router 3G con el cual pudimos sortear la situación y gracias a @gabo y @webcool se grabo audio y video, el cual una vez que este procesado, se va a hacer disponible.

A continuación voy a realizar una pequeña reseña de lo que ocurrió el día de ayer, aunque para un detalle mas completo hay que esperar que el audio y video este disponible.

El inicio fue con la pregunta obligada, ¿Que es el web 2.0?, lo interesante es que se pudo obtener la perspectiva de gente del área de desarrollo de sistemas y de diseñadores gráficos, y aunque no legamos a un acuerdo al 100% si se pudieron identificar algunas características en común:
  • Enfocadas principalmente a redes sociales
  • Twitter
  • Facebook
  • MySpace
  • YouTube
  • Flickr
  • Los usuarios participan en la creación del contenido
  • Co-participan en el contenido ofrecido, por lo tanto el sitio les es mas interesante
  • Digg
  • Enchilame
  • Ofrecen una mejor experiencia de usuario
  • Estándares Web
  • Intercambio de datos XML, JSON
  • Comunicación Asincrona
  • Lógica del lado del clientes, JavaScript
  • Se ofrecen como SaaS (Software as a Service)
Otras características que se mencionaron que pueden ser parte, pero no precisamente implican Web 2.0 son:
  • Botones redondos y diseño de letras grandes y logotipos brillosos
  • Ofrecer un API para, llevando las aplicaciones mas alla del Web
También se comento si las aplicaciones RIA (Rich Internet Applications), como las aplicaciones en Flash y Silverlight deberían ser consideradas Web 2.0 o no.

Posteriormente se discutió del modelo de negocio de las aplicaciones Web 2.0, ya que muchas no cuentan con un modelo definido y sobreviven de "Venture Capitals".

Se menciono que la publicidad es una forma de monetizar, pero no es la única forma, algunas de las aplicaciones tienen versiones lite gratuitas y la funcionalidad avanzada se ofrece con un costo el cual generalmente suele ser accesible.

También se comento que hay empresas que están utilizando a estas aplicaciones para promocionar sus productos y servicios, formando así un ecosistema económico.

Igual se comento que no por todas las aplicaciones Web 2.0 que usamos estaríamos dispuestos a pagar por usarlas, aunque el costo sea muy pequeño, de forma general coincidimos que pagaríamos por las aplicaciones que nos ofrecen un beneficio a forma de servicio, y las aplicaciones de ocio las seguiríamos usando si siguen siendo gratis.

Otro punto fue la parte tecnológica, comentamos que si para hacer una aplicaciones Web 2.0 se debe de utilizar una tecnología en particular o no, el consenso fue que no, pero la tendencia de aplicaciones Web 2.0, es que están desarrolladas en plataformas de lenguajes dinámicos, como PHP y Ruby On Rails. Java y .NET prácticamente no figuran en este ámbito. Desde el punto de vista de los diseñadores mencionaron que, por ejemplo, PHP les ofrece un mejor control sobre el HTML generado a diferencia de .NET.

Después tratamos de conjuntar una lista de aplicaciones Web 2.0 en México y prácticamente nos fue imposible, el único sitio que se menciono fue Enchilame. Buena parte de la conversación se nos fue en mencionar la dis-funcionalidad de los sitios Web de los bancos "Mexicanos", sitios de Gobierno, sitios web de empresas que no ofrecen ningún valor a sus clientes.

Se cuestiono sobre el movimiento Web 2.0 en México, aunque existen movimientos como Café de Altura y Tequila Valley, el desarrollo Web 2.0 es poco visible, ademas de que no existe una forma de acercase a inversionistas si es que los hay. También se comento que es importante seguir el modelo de Estados Unidos, conocido como "Startups", es decir empezar el desarrollo de la aplicación y tratar de ponerla en linea con la finalidad de una vez teniendo el producto funcionando, quizás así sea mas fácil el obtener financiamiento.

Finalmente se discutió si se debe de "clonar" aplicaciones exitosas en Estados Unidos o no, el consenso fue que una copia fiel, no es buena idea, lo mejor es tomar ese "know-how" y complementarlo con necesidades especificas de la zona y si la idea a final de cuentas no es muy original, entonces evitar tratar de competir con la aplicaciones original y mejor enfocarla al mercado hispano.

En general esto fue lo que se comento durante la platica, como recomendación, se comento que es necesario vencer la apatía, no renunciar todavía a sus trabajos de día, pero tratar de llevar nuestras ideas para que se materialicen y con un poco de suerte poder crear un negocio exitoso en Internet.

Estén pendientes a las fotos, audio y video a publicarse en los próximos días.
Gracias otra vez por haber participado y compartido con nosotros.

viernes, marzo 06, 2009

DevLab: TDD, pruebas de unidad.

En el desarrollo de software, ya sea usando metodología "formales" como la ingeniería de software o metodología ágiles, incluyen una fase que se denomina de pruebas.

Hay diferentes forma de realizar las pruebas, una de ellas, y quizás la menos optima, es darle la responsabilidad al programador que esta implementando la funcionalidad a que el mismo realice las pruebas.

Otra forma de hacer es tener un equipo formalmente de aseguramiento de calidad o Q&A.

Ambas opciones generalmente no son pruebas automáticas o que nos aseguren que la mecánica de la prueba va a ser siempre igual o que accidentalmente se omita alguna parte de la prueba.

El resultado derive en que cabe la posibilidad de que nuestro programa presente "bugs" al momento de llegar a producción.

Ante esta situación en la industria de desarrollo de software ha ideado practicas para poder realizar pruebas automáticas sobre el software.

Una de estas practicas es la llamada Pruebas de Unidad o Unit Testing. Las pruebas de unidad consisten en pequeños bloques de código que se ejecutan para probar el código de nuestra aplicación.

Las pruebas de unidad tiene como alcance el probar únicamente la funcionalidad propia de clase en cuestión y no su interacción con otras clases del sistema.

Como una extensión a la realización de pruebas de software, la Técnica Desarrollo Dirigido por Pruebas o Test Driven Development (TDD), nos indica que "alguien" tiene que escribir las pruebas de nuestro código a partir de las especificaciones del mismo, antes que esa funcionalidad sea implementada. Esto se debe a que el objetivo de TDD es dual, primero al escribir las pruebas para código que no existe, estamos realizando el diseño del software que vamos a construir y el segundo objetivo es que las pruebas realizas obedecen a una especificación, por lo tanto es posible identificar en que parte de nuestro software se implemento la especificación requerida.

Referencias


DevLab: TDD, pruebas de unidad from Mario A Chavez on Vimeo.

Material del Screencast

lunes, marzo 02, 2009

Fútbol, matemáticas y otras mentiras

Futbol picanteHace un par de días viendo el programa de Fútbol Picante de ESPN, los comentaristas criticaban la forma en como asignan los partidos a cada arbitro, ya que igual ponen a novatos en partidos donde errores arbitrales pueden causar controversia - por ejemplo partidos donde estén jugando equipos con probabilidades de descender a la 1ra división A -.

En los comentarios se decía que la comisión de árbitros - De la liga Mexicana de Fútbol - en "teoría" no asigna a los árbitros manualmente, para eso existe un "ordenador" que se encarga de asignar a los árbitros, pero los comentaristas se preguntaban cual es el criterio que utiliza dicho "ordenador" para realizar la selección.

Ya que mencionaron que no parece que utilice la información del torneo ni el desempeño previo de los árbitros para decidir que arbitro debe participar en que partido.

Y bueno uno que no tiene nada que hacer, empece a racionalizar sobre como esta funcionando ese "ordenador" y como debería de funcionar.

Tomando como premisa los comentado por los participantes del programa, donde no se puede apreciar un patrón en la asignación de los árbitros, la primera idea que me viene a al mente, es que posiblemente este usando un algoritmo de números pseudo-aleatorios.

Existen varios algoritmos para la generación de numero pseudo-aletorios, en donde se busca que los números generados a partir de una semilla, estén distribuidos lo mas uniformemente posible en una distribución normal, es decir que los números no estén "cargados" hacia algún lado, que tengan un periodo largo, es decir que no se repitan frecuentemente y que sean reproducibles una y otra vez con la misma semilla.

Uno de estos algoritmos es el Congruencial Mixto Lineal, es cual utiliza el numero previamente generado para la generación del numero siguiente:

pseudo

Donde:
X0 = es la semilla ó numero inicial (X0 > 0)
a = el multiplicador (a > 0)
c = es la constante aditiva (c > 0)
m = el modulo (m > X0, m > a y m > c)

Para mas información ir a "Generador congruencial lineal mixto"
Este tipo de generadores se emplean en el desarrollo de aplicaciones de Simulación para eventos discretos, los cuales permiten "modelar" escenarios mediante sistema de computo.

Volviendo al tema principal, si tal "ordenador" es el que asigna los árbitros y utilizar simplemente la asignación aleatoria a partir de numero pseudo-aleatorios, entonces las asignaciones de los árbitros van a seguir siendo como hasta ahorita "erráticas" e ignorando la gran cantidad de información historia que se genera partido tras partido durante un torneo de fútbol.

Si lo que se busca es tomar esa gran cantidad de información disponible y que sistema de computo la analice para determinar cuales son los árbitros mas óptimos para cada partido, entonces estamos entrando en el campo de la Inteligencia Artificial.

La inteligencia Artificial en términos simples, consiste en hacer que un programa de computo funcione lo mas parecido posible al razonamiento humano. Por ejemplo áreas como la lógica difusa son utilizadas para resolver problemas que por medio de algoritmos seria muy complejo describirlos, pero sin embargo se cuenta con mucha información sobre el problema, por lo tanto se utiliza un razonamiento "casi" humano para tomar una decisión a partir de los datos disponibles.

Para hacer uso de IA, se parte de que quizás la información sea necesario "normalizarla", es decir atenuar picos que se van a extremos, el siguiente paso consistiría en modelar una red neuronal en base a la arquitectura elegida para nuestra red neuronal.



En la entrada de los datos a nuestra red neuronal se asigna un peso especifico para cada tipo de dato - por ejemplo a la mejor tiene mas peso especifico el desempeño de un arbitro durante los partidos del torneo, que el peso que tiene el desempeño en el partido anterior, ya que un partido malo lo puede tener cualquiera - los valores de entrada y los pesos para cada tipo de datos conforman lo que se conoce como la función de propagación, esta función se encarga de combinar las entrada y los pesos; una función de propagación común es la sumatoria de los productos entrada-peso.

Activacion

Donde w representa el vector de peso de la entradas y x el vector de entradas a la red neuronal. Una vez que se calcula el resultado de la función de propagación, este valor se pasa a la función de activación o transferencia, la cual puede ser una función lineal, pero es mas común el uso de funciones sigmoidales - logaritmicas -

activacion sig

El resultado de la función de activación se puede comparar con un valor de umbral, para determinar si los datos entrada activan la neurona o no.

La asignación de los valores correctos de los pesos generalmente se hace de manera iterativa, donde a la red neuronal se van asignando valores de entrada, denominados grupo de entrenamiento, y en base al resultado se ajustan los pesos, con la finalidad de ir "creando conocimiento" en nuestra red; a este proceso se le conoce como entrenamiento de la red neuronal.

Una vez que a red ha cumplido con su proceso de entrenamiento, ahora si se le asignan datos de entrada para que con el conocimiento adquirido nos ayude a tomar decisiones factibles, es decir tomar la información del torneo actual, el desempeño de los árbitros y tratar de asignar al arbitro correcto para cada partido.

Aunque el concepto de redes neuronales se escuche muy de ciencia ficción y mas si lo tratamos de emplear a un problema tan vanal como el expresado en el post, la realidad es que muy probablemente utilicemos la inteligencia artificial mas seguido de lo que nos imaginamos, por ejemplo:
  • La cámara fotográfica que realiza focus automático de nuestros objetivos
  • La cámara que busca y enfoca rostros en nuestras escenas
  • La cámara fotográfica que se dispara cuando alguien sonríe
  • El programa que de gestión de fotos que reconoce rostros y nos ayuda a catalogar nuestras fotos
  • La TV HD que toma información de iluminación del programa que se esta transmitiendo e información de luz del ambiente donde se encuentra la TV para así auto-ajustar el brillo y el contraste.
Entre otros muchas aplicaciones mas. Para mas informacion sobre redes neuronales visitar:

Tarjetaroja

En fin un momento de ocio me llevo a un estado de análisis y razonamiento mas alla de lo que yo hubiese querido. Señores de la FemexFut si quieren menos criticas en los árbitros, aquí esta la propuesta de solución, ah y estoy disponible para implementarla ;)

domingo, marzo 01, 2009

Lo importante es que funcione

Hace unos días me encontré con este post titulado "Lo importante es !!! que funcione !!!" y no puede evitar recordar platicas pasadas en donde precisamente me comentaban lo mismo, "lo importante es que funcione".

Y si, en buena medida se tiene la razón, de nada sirve una aplicación que hace uso de todas las practicas y patrones si la aplicación nunca ve la luz.

Pero también existe la otra contraparte - la mencionada en el post -, en donde nos olvidamos por completo de cualquier norma o reglas implícitas o explícitas y simplemente "tiramos" código hasta hacer que nuestro programa funcione.

Ambos extremos son malos desde cualquier punto que se les observe.

La sobre ingeniera de una aplicación, solo viene a causar complejidad excesiva en el desarrollo y mantenimiento de una aplicación, esa complejidad se multiplica cuando se busca realizar cambios o simplemente darle mantenimiento a la aplicación.

El aplicar todas las buenas practicas y patrones, perdiendo de vista el objetivo final, que es el realizar un producto funcional, en tiempo y forma; solamente lleva a que el proyecto sea cancelado en algún momento, causando mal sabor de boca a los desarrolladores, ya que el esfuerzo empleado para lograr una buena aplicación no sirvió de nada, y si se es una empresa pequeña o mediana, obviamente también se refleja en un daño económico, por la perdida del proyecto y posiblemente del cliente.

El no "disponer" del tiempo para realizar un diseño y especificar una arquitectura de nuestra solución, y simplemente "hacer que funcione", desafortunadamente es algo común en las empresas pequeñas a medianas de desarrollo de software, como también en las empresas que no son TI pero tienen sus propios departamentos de desarrollo.

Buena parte de la ideología de "no perder tiempo" en el diseño, patrones y guías, viene de la necesidad de tener el producto terminado cuanto antes, ya que eso significa que se esta en posición de poder cobrarle al cliente cuanto antes, por lo tanto cualquier situación que "retrase" el tiempo de entrega se ve como un enemigo a tener los recursos económicos a tiempo en las empresas.

En las empresas no TI, desafortunadamente en muchos de los casos gente no TI compromete tiempos de desarrollo, en base a prácticamente nada, ante esta situación, pues también se piensa en "no perder tiempo" en el desarrollo y hacer que la aplicación funcione.


El argumento más común para implementar el proceso "haz que funcione", viene de la idea que para poder implementar un diseño y una arquitectura de nuestra aplicación implica "perder tiempo", quizás evitando esta parte fundamental del desarrollo de software, si sea posible tener un entregable en tiempo, pero la pregunta es: ¿A que costo?

Si bien todo software tiene un tiempo de vida antes de volverse "legacy", siguiendo la "metodología" "haz que funcione" acelera esta situación por las siguientes razones:
  • Es muy difícil entender el código, posiblemente únicamente la persona que lo desarrolló, es el que "puede" tener un entendimiento aceptable.
  • Existe una mayor posibilidad de tener "bugs" extraños y difíciles de duplicar y corregir.
  • El realizarle cambios al programa se vuelve cada vez mas complejo, porque no entendemos hasta que punto esos cambios van a afectar otras áreas de nuestro programa.
  • No hay forma de reproducir situaciones muy particulares que ocurren con nuestro software y si este inter-actua con otro mas, lo mas común es culpar al otro software.
  • Inicialmente quedamos "bien" con el cliente por entregar el software a tiempo, a la larga los errores y fallas de nuestro software nos ponen en una situación no muy buena, y si a esto le agregamos que le cobramos al cliente por arreglar nuestros "errores", pues todavía peor.

El caso es encontrar el punto medio, si como empresa de desarrollo no seguimos buenas practicas para el desarrollo de nuestras soluciones, tratar de implementarlas de un momento a otro, únicamente va a producir un desastre y volveremos a las viejas practicas al instante.

Es necesario identificar las practicas que pueden traer un beneficio mayor a nuestra organización y primeramente "evangelizar" entre nuestro grupo de desarrollo antes de siquiera intentar implementarlas, una vez que decidimos implementarlas, es importante comenzar un tanto relajados en su aplicación, una vez que el equipo se haya acostumbrado, entonces empezar a "apretar" poco a poco para que estas se cumplan.


Actualización: En el blog de Eber Irigoyen, el comenta sobre la idea de "Deuda Técnica" a este problema de únicamente hacer que funcione.

Imagén notebook MyImageCollections
Imagén diseño subWiz
Imagén de los problemas de software Ryan Coleman
Imagén Programador frustrado Sybrem A. Stuvel