viernes, 29 de noviembre de 2013

Conociendo un poco del potencial de los frameworks de Java script

Este año he logrado conocer algunos frameworks MVC para Java script. Al inicio luego de muchos años de conocer el potencial de ASP.net, me sentí empezando en un mundo extraño donde la sintaxis del lenguaje era diferente, donde varias cosas de las cuales estaba acostumbrado desaparecieron y francamente me sentí como empezando de nuevo.

La aventura inicio con Backbone.js. Nunca había visto mis páginas web cargar tan velozmente e interactuar con tanta fluidez. Lo mejor la reutilización de código con n cantidad de vistas en una página fue una de las mejores cosas que le vi. Además de la tener código tan estructurado en un lenguaje como javascript donde estaba acostumbrado a hacer cosas como una librería .js con un montón de funciones guardas en desorden y compartiendo variables en forma desordenada. Además la documentación que  presta la página oficial creo que es suficiente para entender muchas de las funciones. El contra lo único que puedo decir es que es un poco de configurar y entender al inicio, pero uno aprende a crear java script de forma ordenada y como debe de ser. Además de que necesita la ayuda de otras librerías para tener un proyecto bastante fácil de usar.

http://backbonejs.org/


Posteriormente, conocí Angular.js. Este es un framework con mas documentación, mas estructurado, mas fácil de entender, se puede crear cosas a la primera de forma muy fácil ya que es muy intuitivo y con cada versión Google que es el dueño le incorpora mas funcionalidades al punto de que casi no hay que agregar mas librerías al proyecto, Angular lo hace casi todo.  Además como Google mantiene le proyecto hay muy buena documentación. Actualmente creo que esta dentro del Boom de los Frameworks MVC de JavaScript y va a ganar más terreno. Lo mejor de Angular son las directivas, que trabajan modificando el DOM de esta forma puedes hacer muchas cosas de una forma mas dinámica y con menos codigo.

 http://angularjs.org/


Ahora cual es la ventaja de un framework MVC? Creo que la mayor ventaja de esto es tener páginas web mas rápidas y robustas. En si el modelo se conecta a un servicio en muchos de los casos RESTFull, el controller rápidamente sabe cómo manejar los datos para hacer que estos persistan o para mostrarlos en pantalla y la vista es un html que dinámicamente aparece en nuestra página web. Las ventajas es que las paginas se ejecutan directamente en el navegador del cliente y en el servidor solo exponemos servicios. Además, nos da la oportunidad de colocar nuestro proyecto web en cualquier servidor http.

En sí, ya me olvide del page_load de ir y venir al server y mostrar molestos postbacks refrescando la pagina, y de tener paginas tediosamente lentas. Acá les dejo algunos links para que continúen su aprendizaje en estos frameworks:

sábado, 14 de abril de 2012

Creado Code Snippet en Visual Studio


Muchas veces en nuestros proyectos tenemos métodos o páginas web con estructuras similares, pero que según el comportamiento de cada una deben de cambiarse. Tal vez tenemos una página web como un mantenimiento que siempre tiene el mismo comportamiento pero diferente cantidad de campos a ser editados, o un webService que recibe una clase request y envía una clase response como respuesta y que tienen cierta herencia que hace que siempre se debe de heredar de una clase especifica o se deban de usar métodos específicos.
Entonces siempre tenemos que estar copiando y pegando todo el contenido de un archivo y pegándolo en el archivo nuevo y después de eso quitar todo lo que no ocupamos y empezar la edición. Tomando eso en cuenta, uno se percata que está perdiendo mucho el tiempo siempre copiando pegando y eliminando lo innecesario, y que esto nos puede llevar a errores que a veces duramos mucho en resolver. Buscando una solución se me vino a la mente crear code snippet y templates en visual studio para evitarnos este proceso.

Como crear code snippet en Visual Studio
·         Creamos un archivo de texto le damos el nombre de snippet y le colocamos la extensión .snippet este es un archivo XML que va a contener el código de nuestro snippet.
·         Editamos el archivo el cual va ser algo como esto, la primera parte es crear el encabezado de nuestro archivo.

<?xml version="1.0" encoding="utf-8"?>
<CodeSnippets xmlns="http://schemas.microsoft.com/VisualStudio/2005/CodeSnippet">
  <CodeSnippet Format="1.0.0">
    <Header>
      <SnippetTypes>
        <SnippetType>Expansion</SnippetType>
      </SnippetTypes>
      <Title>MiMetodo</Title>
      <Shortcut>Mi Metodo</Shortcut>
      <Description>Ejemplo de un Snippet</Description>
      <Author>rlamunoz</Author>
    </Header>

  • En Title agregamos el titulo del snippet tal y como aparecera en visual studio
  • En Shortcut agregamos un nombre o forma corta de encontrar nuestro snippet
  • En Descripction agregamos la descripción de que hace nuestro snippet
  • En Author agregamos quien creó el code snippet

Seguido en el XML viene la estructura de los campos que va a solicitar la plantilla cuando sea utilizada desde Visual Studio.


    <Snippet>
      <Declarations>
        <Literal Editable="true">
          <ID>NombreMetodo</ID>
          <ToolTip>Nombre del Metodo</ToolTip>
          <Default>MetodoPrueba</Default>
          <Function>
          </Function>
        </Literal>
        <Literal Editable="true">
          <ID>Descripcion</ID>
          <ToolTip>Descripción del Método</ToolTip>
          <Default>Ingresar la descripción del método.</Default>
          <Function>
          </Function>
        </Literal>
   </Declarations>

Para cada uno de los campos que queremos variar en nuestro método vamos a agregar un literal el cual es editable.

  • En ID agregamos el nombre del campo variable.
  • En Tooltip agregamos una pista de que es lo que debe de ir en ese campo
  • En Default agregamos el valor por default del campo, en el caso de que el nombre del método se omita este va a ser MetodoPrueba.

·         Una vez que tenemos los campos que serán editables debemos de crear el método y colocar cada literal dentro de este, para colocar los ID de los literals dentro debemos de hacerlo de la siguiente forma $NombreMetodo$

<Code Language="csharp">
<![CDATA[/// <summary>
                /// Método: $ NombreMetodo $
                /// Descripción: $ Descripcion $
                /// </summary>
                /// <remarks>
                ///</remarks>
                /// <param></param>
                /// <returns></returns>
public void  $ NombreMetodo $()
{
        try
                    {

        }
        catch (Exception objExcepcion)
                   {
                              
       }
}
]]></Code>
                 </Snippet>
 </CodeSnippet>
</CodeSnippets>

Este es un ejemplo muy básico, pero supongamos que dentro del método tenemos programación que siempre es la misma y los cambios son muy pocos. Salvamos el archivo y tenemos nuestro snippet.
Ahora lo que vamos a hacer es instalarlo en visual studio para poder utilizarlo en nuestros proyectos
·         En visual studio vamos a Tools y elegimos Code Snippets Manager o mediante el teclado Ctrl + K, Ctrl +B, esto nos abre la siguiente ventana:




·         En la pantalla seleccionamos el Lenguaje en el que vamos a agregar nuestro snippet, en mi caso selecciono C#. Selecciono la carpeta My Code Snippets y pulso el botón import… el cual abre una ventana donde voy a buscar el archivo .snippet que creamos anteriormente. Pulsamos el botón OK, y listo podemos utilizar nuestro snippet.
·         Para utilizar el snippet dentro del código solo deben de utilizar el juego de teclas Ctrl+k, Ctrl+X y seleccionar el snippet buscándolo por el nombre.

sábado, 12 de noviembre de 2011

Quitándole los miedos a Windows 7

Unos dirán es muy amigable con el usuario, otros dirán el no quiere que nada le pase a mi sistema operativo o a el mismo, otros es patico, otros es odioso y otros como yo es fastidioso parece que tiene miedo de hacer lo que le estoy pidiendo. Pues bien estoy hablando de las ventanas de solicitud de permisos de administrador de Microsoft Windows 7 Para muchos que utilizamos la computadora todo el día y que trabajamos con diversas herramientas es muy molesto estar viendo esta ventana todo el tiempo, o estar recordando da clic derecho ejecutar como administrador.

Pues bien averiguando un poco en la red después de incomodarme de estar viendo la ventanita esta, encontré la forma de quitarla. Lo único que debes es escribir en la cajita de texto de búsqueda del menú de inicio de Windows 7 el comando UAC (Control de cuentas de usuario) y darle enter. Posterior a eso se despliega una ventanita como esta:



En esta ventanita tenemos las siguientes opciones:

  • Siempre notificarme y esperar mi respuesta. Se muestra la solicitud de confirmación del UAC en el escritorio seguro cuando un programa intenta instalar un software, o cuando un usuario o un programa intentan cambiar la configuración de Windows. Si no hace clic en Sí, después de 30 segundos la solicitud de confirmación del UAC deniega automáticamente la solicitud. 
  • Notificarme siempre. Se muestra la solicitud de confirmación del UAC en el escritorio cuando un programa intenta instalar un software, o cuando un usuario o un programa cambian la configuración de Windows. Si no hace clic en Sí, después de 30 segundos la solicitud de confirmación del UAC deniega automáticamente la solicitud. 
  • Sólo notificarme cuando un programa intenta hacer cambios en mi equipo. Sólo se le notifica cuando un programa intenta hacer cambios en el equipo, incluidos los cambios en la configuración de Windows. 
  • No notificarme nunca. Esta opción deshabilita el Control de cuentas de usuario.

Selecciona la que más te agrade, a mi me gusta la ultima porque Windows me deja en paz y es la que tienen que marcar para tener un sistema operativo donde uno decide que hacer y no le están preguntado que si se puede, que si está seguro, y que si esta seguro de estar seguro.


sábado, 12 de marzo de 2011

SCRUM

Este año lo empecé pasándome a utilizar otra metodología de desarrollo de software  SCRUM, muy diferente a la pseudo-Cascada que utilizaba anteriormente. Pues bien se establecieron las reglas del juego y quiero compartirlas con ustedes.


¿Qué es SCRUM?
 SCRUM es un metodología de desarrollo Ágil, la que consiste en que el cliente siempre va a poder ver parte del producto terminado y no debe de esperarse hasta el final, como en cascada. Esto nos da una serie de ventajas como lo son:

  •  Mejora la calidad del desarrollo y hace que el proceso siempre sea una mejora continua ya que se retroalimenta a sí misma.
  •  Los programadores se sienten más a gusto, pues ellos son los que eligen que hacer de las tareas del product backlog. Esto hace que el equipo sea cada vez más productivo
  •  Los clientes están contentos, pues cada vez que un sprint termina se les entrega una parte funcional del sistema, la cual puede si se quiere estar en producción. Siempre se hace una integración continua y el sistema crece con cada entregable
  •  A la hora de realizar cambios en lo solicitado por los usuarios se tiene más flexibilidad, permitiendo a los usuarios poder revisar detalladamente la aplicación mientras se continúa con el proceso.

¿Cómo se lleva el proceso a la práctica?
SCRUM no es una metodología sin metodología como dicen por ahí, es una metodología que permite ajustarse a las necesidades del proceso de los equipos, para que estos tengan una mejora continua y sean cada día más productivos.

Como trabajar con SCRUM
Lo primero que se hace es conocer las necesidades del usuario, esas historias que deben de terminar en un caso de uso donde se especifica como el usuario y el sistema interactúa. El caso de uso debe de ser lo más consistente posible ya que como un history debe de indicar las necesidades del cliente y como el sistema deberá de responder a estas.  Hemos visto en nuestro proceso de día a día que los casos de uso son la mejor herramienta para hacer un análisis de que es lo que el usuario necesita y como los ingenieros que están a cargo de este proceso creen que el sistema debe de interactuar.  Pero primero es escuchar las necesidades que el cliente priorice estas necesidades y según las prioridades empezar a obtener los casos de uso. Una vez que tenemos los casos de uso se deben de priorizar para saber que se debe de hacer en cada una de las iteraciones de desarrollo.

Una vez que tenemos los casos de uso priorizados, y tenemos las demás historias esperando por ser analizadas,  el cliente determina que quiere que se desarrolle en cada iteración, el equipo define el tamaño de cada iteración por lo común son 4 semanas de desarrollo y 1 de pruebas, para continuar  con otra iteración, se define cada cuanto se van a entregar el producto al cliente; puede ser cada 2 iteraciones o cada iteración y esto es entregado al finalizar la iteración. Una vez que se establecieron estas reglas simples inicia el primer sprint.


SPRINT o iteración

El equipo ya tiene priorizado por el cliente que desea que  se desarrolle así que se determina el peso para cada una de las tareas que se van a desarrollar en el SPRINT, para esto se leen los casos de uso y el equipo debe de votar  por un peso, puede usarse una serie para determinar el peso (0,1/2,1,3,5,8,13,20,?) En esta página pueden ver como se realiza el proceso (http://www.crisp.se/planningpoker)  esta parte es muy divertida ya que todo el equipo interactúa.  Pero hay un problema, cuando se inicia en la metodología porque como todo en esta metodología consiste en una mejora continua y aprender del proceso, por eso al inicio debemos de medir la velocidad del equipo y estar revisando si exactamente los pesos que establecimos al inicio se ajustan al final, para así poder en un futuro determinar fácilmente cual es el peso  para una tarea y no estar como comúnmente decimos bateando.

Mi equipo estableció las reglas para el SPRINT y para poder ir determinando la velocidad del equipo y de cada uno de los integrantes. Estas son las reglas que determinamos:

      1.Se hace una reunión de Daily SCRUM todos los días a las 9:00 am o más o menos a esa hora, durante la fase de desarrollo del SPRINT. En estas reuniones el SCRUM Master elegido por el equipo pregunta a los demás compañeros del equipo qué están desarrollando, cuanto estimaron en tiempo de duración para las tareas y si tienen algún problema para completar sus objetivos.

      2.La pizarra se divide en partes según se avanza en el SPRINT, esto es lo que se ajusta según las necesidades del equipo y acá como lo implementamos nosotros:
  • Producto Backlog, todo lo que se desarrollara en el SPRINT
  • Selected by Dev, cuanto un ingeniero selecciona una tarea a desarrollar le coloca su nombre a la ficha y se adueña de la tarea.
  • TO DO, al ingeniero seleccionar una tarea y hace una serie de papelitos donde despedaza por así decirlo la tarea general en subtareas (Divide y vencerás) para cada una de las tareas estima el tiempo que durará realizando la tarea. Esto lo hace el ingeniero una vez que ha leído el caso de uso y entiende a que se refiere lo que debe de hacer.
  • IN PROGRESS, cuando el ingeniero va a empezar a programar entonces el toma uno de los papelitos del TODO y lo pasa al IN PROGRESS al hacer esto coloca en el papelito a qué horas inicio la tarea y que día inicio la tarea, al final esta información nos servirá para determinar de cierta forma la velocidad del equipo y como poder estimar mejor las tareas.
  • Test and DOC,  Cuando el ingeniero termina una tarea en el IN PROGRESS, coloca en el papelito la hora en que termino la tarea y la fecha, así de una vez calcula cuanto duro en la construcción de esa tarea y coloca en el papelito el tiempo real que duro en terminar la tarea. Una vez que hace esto mueve dicho papelito a Test and DOC. Una vez que todos los papelitos del TODO están en test  and DOC el ingeniero procede a realizar pruebas unitarias de lo que construyo, finalizadas las pruebas unitarias el ingeniero realiza la documentación necesaria para el usuario. El tiempo que dura realizando esta tarea queda implícito en  las tareas del TODO pues cada uno de los papelitos debe determinar el tiempo que se dura probándose y documentándose.
  • DONE, una vez que se tiene todo documentado y probado se pasa la ficha del Selected by Dev a Done, en la ficha se coloca el tiempo estimado, sumando el tiempo estimado de todos los papelitos del TODO y también se coloca el tiempo real, sumando el tiempo real de todos los papelitos que se crearon en el  TODO .
  • Una vez que el ingeniero termino con una tarea debe de volver al producto Backlog y seleccionar una nueva tarea. A esto se le conoce como una iteración dentro del SPRINT.  

       3. Al finalizar la programación cada uno de los miembros del equipo debe de seguir una guía para            revisar punto a punto cada una de las tareas que realizo y hacer pruebas unitarias, finalizadas estas pruebas se inicia un nuevo proceso de pruebas donde en ingeniero X revisa las tareas realizadas por el ingeniero Y, una vez que se terminan las revisiones el ingeniero Y le entrega un documento de pruebas al ingeniero X para que este proceda con los cambios pertinentes.

       4. El último paso es hacer un historial de los casos de uso resueltos, colocando el tiempo estimado y el tiempo real para cada una de las tareas, así como la cantidad de peso asignada a la ficha. Se debe de estimar un nuevo peso si es el caso para que en el futuro el ingeniero se refiera a estos casos para que sepa cuando dura resolviendo una tarea específica. Afinando cada  vez este proceso se puede determinar con más facilidad la velocidad del equipo y la velocidad de cada uno de los ingenieros involucrados.

       5. Realizados todos estos pasos, se debe de hacer la presentación del producto y entregar una versión para pruebas del usuario. El equipo hace una reunión de retrospectiva donde discute si debe de hacer cambios en el proceso de SCRUM o si debe dejar la metodología igual. Es discutir que les pareció el proceso a todos y que se debe de mejorar. Recordemos que la metodología busca tener siempre un equipo productivo y contento con su trabajo y su forma de trabajo. 




Si quieres saber más sobre SCRUM te invito a buscar en la web información referente al tema, esta forma en cómo yo explique las reglas de mi equipo tal vez solo se puedan utilizar en mi equipo y en mi proyecto, pero con algunas variantes puede funcionar correctamente en tu equipo de trabajo. Te invito también a revisar el manifestó de Ágil (http://agilemanifesto.org/iso/es/principles.html) y si estas utilizando una metodología Ágil firma el manifestó (http://agilemanifesto.org/sign/display.cgi?ms=000000201)