martes, 30 de diciembre de 2014

Nintex ahora cubre ofertas de servicios nuevos y mejorados

 

image

image

 

 

El Soporte Platinum es un nuevo offering de Nintex que le da servicio enterprise real.

LOS BENEFICIOS INCLUYEN:

image

Soporte 24 x 7 por teléfono , chat, e email
Soporte modelo “follow-the-sun” Agentes trabajando en tu issue las 24 horas del día , 7 días a la semana, 365 días al año.

image

Tiempo de respuesta en Cuatro horas
El Soporte de Nintex intentará conectarte dentro de las cuatro horas de la emisión del issue.

image

Ocho horas de guia de migración con soporte de un ingeniero
Nuevo offering para los clientes que están planeando migrar a nuevo hardware, plataforma o a la nube.

 

Nintex también está ofreciendo mejoras al soporte Premium:
• El contacto via teléfono o chat está ahora disponible 24x5
• Tiempo de respuesta en ocho horas
• Soporte Global

 

Beneficios Software Assurance Premium Support Platinum Support
Nuevos Releases

SI

SI

SI

Soporte Online, Email y Chat

SI

SI

SI

Soporte Telefónico

NO

SI

SI

Horas de soporte

8x5

24x5

24x7

Tiempo de respuesta

El mejor esfuerzo

8 horas

4 horas

Licencias no productivas

1:1

Ilimitado

Ilimitado

Cobertura Global

NO

SI

SI

Guia de migración

NO

4 horas

8 horas

 

Contactanos y veamos cual es la mejor opción para ustedes.image

viernes, 19 de diciembre de 2014

Sharepoint - Mapeando Vistas a Folders

 

Les dejo un video hecho para Channel9 de Microsoft, en el marco de #100devdays , de una breve introduccion a esta funcionalidad poco conocida de Sharepoint, y muy util en muchos casos.

 

image

viernes, 12 de diciembre de 2014

Internet de las Cosas

 

clip_image002

Internet de las cosas es el nuevo concepto que trata de acoplar y unir a aquellas tecnologías que permiten interconectar objetos, para hacerlos inteligentes, facilitarnos su uso y optimizar nuestro tiempo.

Imaginemos el siguiente escenario. Vamos al supermercado con nuestro automóvil y lo estacionamos en la playa de estacionamiento.

Mientras realizamos las compras, alguien imprudentemente, con otro automóvil le da un golpe al nuestro, el cual es inteligente.

Entonces, realiza una evaluación de daños, envía un informe a la empresa de seguros. Esta se pone en contacto con nosotros, llamándonos al celular, para notificarnos el incidente y coordinar una fecha para que sea revisado por un perito.

En el mismo instante, la compañía de seguros hace contacto con las cámaras de seguridad del estacionamiento e identifica, por medio del reconocimiento de patente, el vehículo y al conductor que produjo el choque.

Todas estas acciones, sin la necesidad de realizar ningún trámite adicional y sin haber dejado de hacer las compras.

clip_image004

Con este ejemplo, la directora de investigación de IDC, Marta Muñoz, explica en que consiste Internet de las cosas (IoT, Internet of Things).

Estamos frente a una tendencia, que viene desde hace un tiempo, pero ¿Estamos preparados?

Una de las ventajas es que cualquier sector puede beneficiarse de estas tecnologías, siempre que existan dispositivos, redes, capacidad de análisis de datos en tiempo real y procesos que establezcan de manera clara los pasos a realizar, que hasta hoy no existían.

IDC prevé que para el año 2020 internet de las cosas generará ingresos por más de 7 billones de dólares a nivel mundial. Para ese entonces, existirán 200 mil millones de cosas y dispositivos conectados a redes presentes en cualquier ámbito de nuestra vida.

Para cumplir con estas expectativas hay empresas, como Intel, trabajando para acelerar su adopción, cuyo departamento de desarrollo en conjunto con antropólogos que estudian la relación humana con la tecnología, para anticiparse a esta tendencia.

Intel está enfocando sus esfuerzos en impulsar proyectos que ayuden a conectar los miles de millones de dispositivos existentes en internet desarrollando, entre otros, procesadores de bajo consumo y servidores que permitan transformar los datos a gran escala en información útil.

Otro de los desafíos a los cuales se deberá enfrentar es la prueba final que involucra conocer si los usuarios están listos para utilizar toda esta tecnología a diario.

A futuro el objetivo de IoT es encontrar la manera de que apenas nos demos cuenta de lo que sucede con las cosas y que muchos procesos automatizados nos simplifiquen la vida de manera trasparente y nos permitan aprovechar mejor el tiempo, nuestro único recurso no renovable.

 

No todo es color de rosa…

Los objetos inteligentes no están exentos de sufrir ataques malintencionados.

Es importante entender que, del mismo modo que internet de las cosas está haciendo posible un mundo más eficiente y mejor conectado, también ofrece a los ciberdelincuentes una red más preparada para lanzar sus ataques.

clip_image006

Estas son alguna claves importantes para quienes se centren en esta nueva tendencia:

· Aunque algunos dispositivos, por el momento, no se puedan conectar a Internet, sí lo hacen los sistemas que los ejecutan. Los delincuentes buscarán una vulnerabilidad en el servidor, y una vez dentro, se moverán por redes locales hasta alcanzar su objetivo.

· Si actualmente dos de cada tres ordenadores están infectados por botnets, resulta importante pensar qué sucederá cuando más de 200 mil millones de dispositivos puedan ser usados con este fin.

· Muchos de los dispositivos inteligentes tienen una capacidad de procesamiento limitada y no son capaces de ejecutar soluciones antimalware convencionales. La seguridad se basa en el cambio de contraseña del usuario y la configuración a distancia, por lo que tenemos que garantizar que no haya ninguna puerta abierta.

· La aplicación de actualizaciones y parches y el despliegue de capas de seguridad, debería de ser una de las prioridades de este reto tecnológico.

· Cada vez hay más datos personales diseminados en diferentes dispositivos que, con el internet de las cosas, se incrementará exponencialmente.

¡Gracias Hernán Gil por tu contribución!

martes, 14 de octubre de 2014

¿Cómo aprovechar la virtualización en testing?

 

La virtualización es un conjunto de recursos tecnológicos que permiten simular desde datos o componentes de sistemas hasta entornos completos de trabajo (máquinas virtuales, servidores, sistemas operativos, etc.), que facilitan y, en ocasiones críticas, permiten la ejecución de pruebas aún cuando no existen los recursos físicos disponibles o cuando los desarrollos están incompletos. Esto ocurre, por ejemplo, con los drivers o stubs.

Particularmente, la virtualización de servicios es la capacidad de simular los componentes de servicio de modo que permita validar el comportamiento y el rendimiento de cada uno de los componentes y la forma en que interactúan como parte de una aplicación compuesta. La virtualización de servicios ayuda a no tener que esperar a que todos los componentes estén disponibles y se despliegan para comenzar las pruebas de extremo a extremo. Es posible virtualizar aplicaciones y sistemas que no están disponibles para probar el rendimiento de aplicaciones y el comportamiento en el ciclo de desarrollo tales como aplicaciones SOA y BPM.

Dado lo anterior, el tener elementos que permitan diseñar y ejecutar las pruebas en etapas tempranas del proyecto, no sólo reduce los costos de dicho proyecto, sino que constituye un mejor aprovechamiento de los recursos humanos en el área de testing. Es decir, que el ahorro no sólo es en el hardware sino que también en la aplicación del proceso de pruebas en etapas tempranas, por lo cual consideramos que las principales ventajas de tener entornos de virtualización son:

 

  • Aprovechamiento físico de los servidores: permite que varios entornos, aplicaciones, sistemas e incluso servidores que antes eran físicos convivan en un solo hardware.
  • Mantenimiento operativo: proporciona espacios para la instalación de herramientas de pruebas comunes, darle mantenimiento a estas herramientas y en caso de requerirlo,  eliminarlas para cubrir así las necesidades del usuario.
  • Optimización de recursos: permite que las estaciones de trabajo amplíen su vida útil ya que pueden instalarse versiones más recientes o versiones de prueba de sistemas operativos actuales, aprovechando al máximo las características del hardware (memoria, puerto, procesador, etc.).
  • Sencillas copias de seguridad: las máquinas virtuales se pueden salvar muy fácilmente, porque a fin de cuentas, no son más que una carpeta en un ordenador; en caso de desastre se puede recuperar la información con rapidez y en caso necesario incorporarse a otro lugar físico.

Algunos software de virtualización son: VMware, vSphere, Microsoft Hyper-V, Citrix XenServer, Rational Test Virtualization Server y Rational Test Workbench.

 

¡Gracias por su contribución Sandra Lilia Martínez Ramos y Christian Fabila Domínguez!

jueves, 9 de octubre de 2014

Trabajando con Múltiples Instancias de jQuery

 

clip_image002Algunos tipos de Aplicaciones Web modernas, como las que están desarrolladas en SharePoint, ofrecen características modulares, en donde cada componente de la misma debe poder funcionar de forma autónoma y a la vez integrada al resto; con lo cual si utilizamos jQuery como parte de nuestra arquitectura, debemos considerar el escenario de tener o prever múltiples instancias de dicha biblioteca en una misma Página Web para evitar errores.

jQuery, junto a jQueryUI, son dos de las bibliotecas más utilizadas en los desarrollos de Aplicaciones Web modernas, sin lugar a dudas, debido a los múltiples beneficios que ofrecen, entre ellos: la posibilidad de desarrollar mejores aplicaciones, con un menor esfuerzo, más usables, con una mejor respuesta de cara al usuario, permitiendo integrar miles de plugins y bibliotecas desarrolladas por terceros, resolviendo la compatibilidad Cross-Browser, entre otros.

Para explicar cómo trabajar con múltiples instancias de jQuery, vamos a tomar como ejemplo el desarrollo de un Sitio SharePoint, con varias WebParts que deben poder funcionar tanto en nuestro sitio, como en otros sitios de la compañía; es decir, deben poder funcionar independientemente de la página y del resto de las WebParts.

Trabajar con Múltiples Instancias de jQuery

El primer caso a mostrar es cómo trabajar con dos o más instancias de jQuery, de forma de evitar sobrescribir las instancias previas de esta biblioteca que hayan sido cargadas por la Página Web u otra WebPart que se haya cargado en la misma página.

Esto es deseable cuando queremos que nuestra WebPart funcione independientemente de la versión de jQuery que se haya incluido en la página (por ejemplo, si necesitamos una versión más reciente de la que se provee por defecto).

Para ello, lo que vamos a hacer es incluir en la misma WebPart nuestra propia referencia a la versión de jQuery que deseamos utilizar, y vamos a inicializarla utilizando el operador $.noConflict(true), tal como se muestra a continuación:

<!-- Cargar jQuery 1.9.1 -->

<script type="text/javascript" src="Scripts/jQuery/jquery-1.9.1.js"></script>

<script type="text/javascript">

var $_191 = $.noConflict(true);

</script>

<!-- Usando la Versión 1.9.1 de jQuery -->

<script type="text/javascript">

$_191('#selector').function();

</script>

De esta forma, vamos a poder utilizar la instancia $_191 en vez de la instancia $, que en nuestro ejemplo se corresponde con esta versión específica de jQuery. Si deseáramos poder acceder a la instancia cargada por defecto, siempre podremos usar el operador $.

Además, como puede apreciarse, al no sobrescribir la instancia por defecto, el resto de la página seguirá funcionando como si la nueva instancia jamás se hubiera cargado, ya que trabajará de forma aislada. Para terminar de comprender esto último, veamos el siguiente ejemplo:

<!-- Cargar jQuery 1.8.3 [Por Defecto de la Página] -->

<script type="text/javascript" src="Scripts/jQuery/jquery-1.8.3.js"></script>

<!-- Cargar jQuery 1.9.1 -->

<script type="text/javascript" src="Scripts/jQuery/jquery-1.9.1.js"></script>

<script type="text/javascript">

var $_191 = $.noConflict(true);

</script>

<!-- Usando la Versión 1.8.3 de jQuery [Por Defecto de la Página] -->

<script type="text/javascript">

$('#selector').function();

</script>

<!-- Usando la Versión 1.9.1 de jQuery -->

<script type="text/javascript">

$_191('#selector').function();

</script>

Trabajar con una Única Instancia de jQuery

Por otro lado, puede suceder que con tener una única instancia de jQuery sea suficiente, con lo cual se nos plantea la necesidad de validar si ya ha sido previamente cargada o no.

Una buena práctica para lograr tener una mejor performance en nuestra Aplicación Web es no volver a cargar componentes que ya han sido cargados previamente, es decir, si ya existe una instancia de jQuery, no deberemos volver a cargar el .js correspondiente. Si bien los Browsers modernos detectan estos casos y no ejecutan el Request, igualmente consumimos recursos que podrían aprovecharse para otra cosa.

Además, en el caso de ejemplo, si volvemos a cargar la biblioteca jQuery, podríamos sobrescribir la versión específica que cargó la página, pudiendo generar errores en el resto de los scripts de la misma o de los componentes que cargue la página.

Para cargar la biblioteca jQuery sólo si ésta no ha sido cargada previamente, deberemos utilizar la siguiente condición:

<script type="text/javascript">

if (!window.jQuery) {

document.write('<script type="text/javascript" src="Scripts/jQuery/jquery-1.8.3.min.js"></' + 'script>');

}

</script>

Como podemos apreciar, se verifica mediante un if que no exista la instancia por defecto de jQuery, en cuyo caso generamos un tag <script> que permita referenciar el .js en cuestión. Si ya existiera la instancia, el tag no se generaría, y por lo tanto el Browser no intentaría cargar nuevamente la biblioteca.

De esta forma, podemos cubrir los dos escenarios posibles, cargar una instancia propia de jQuery, o reutilizar una cargada previamente. Cuándo utilizar un esquema o el otro, dependerá de las necesidades de cada proyecto y puntualmente de cada funcionalidad que debamos implementar.

Ing. Ariel Martín Bensussán

.Net Practice Manager

 

¡Gracias por tu contribución Ariel Bensussán!

martes, 7 de octubre de 2014

Particiones en SSAS

 

1 - Introducción

1.1 - Objetivos

El objetivo de este Knowledge Package es explicar el uso de particiones y agregaciones (Aggregations) en SQL Server Analysis Services (SSAS).

1.2 - Alcance

Los ejemplos están basados en SSAS 2012 pero los conceptos aplican a otras versiones de Analysis Services como por ejemplo 2005, 2008 R1 y 2008 R2.

2 - Particiones

Las particiones son usadas a la hora de dividir un measure group (tabla de datos) en partes más chicas, estos datos son divididos de forma lógica y solo a nivel del SSAS. El código usado para crear una partición es SQL. Un select basado en todos los campos del measure group (tabla de datos), pero aplicando filtros (rangos) para dividir la tabla en las particiones.

2.1 - Ventajas de usar particiones

Una de las ventajas de usar particiones es que a la hora de procesar el cubo, no hace falta procesar el measure group completo, sino que se pueden seleccionar particiones, de esta forma, se reducen los tiempos de proceso y la carga sobre el servidor de SSAS. Por ejemplo, en una carga diaria de datos, solo haría falta procesar siempre la última partición que la que se estaría actualizando diariamente, y una vez por semana es recomendable hacer un full process del cubo.
Siempre que se agrega un measure group al cubo, se crea por default una partición basada en ese measure group (tabla completa). El motor de SSAS ejecuta queries que poseen menor cantidad de datos a lo que seria ejecutar una query contra el measure group completo. No es lo mismo para el motor ejecutar un query que agrupa datos de 10 años, a tener 10 queries que agrupan datos de un año en particular.

2.2 - Recomendaciones

Asegurarse que al aplicar los filtros no se esté repitiendo datos en 2 particiones diferentes. En otras palabras, asegurarse que los rangos de filtrado, no se superpongan ni hagan que se pierdan datos. Ya que cuando se trabaja con "<","<=",">",">=" y fechas es muy factible que se repitan 2 fechas en diferentes particiones.
No siempre es recomendable crear particiones, si las tablas son chicas, en estos casos no haría falta crear particiones. Cuando la tabla supera las 3 millones de filas, en esos casos empieza a ser recomendable el uso de particiones. El tamaño recomendado es 20 millones de tuplas por partición, o máximo 250 MB(SSAS 2012).

2.3 - Modos de almacenamiento:

Son las formas en que las particiones guardan los datos. Tener en cuenta que cada particion puede tener su propio modo de almacenamiento.

2.3.1 - MOLAP (Multi dimensional Online Analytical Processing)

Es el más usado, apunta al la performance del cubo(tiempo de respuesta bajo).Los datos y agregaciones son guardados por el motor de SSAS. Los cambios de datos en las tablas van a ser reflejados en el cubo, una vez que este sea procesado o la partición procesada.

2.3.2 - ROLAP (Relational Online Analytical Processing)

A diferencia de MOLAP, el ROLAP no hace una copia de los datos al SSAS, sino guarda los datos en vistas indexadas, pero en el motor de base de datos. El tiempo de consultas y proceso es más lento, pero la gran ventaja es que permite ver los datos de las tablas en tiempo real.

2.3.3 - HOLAP (Hybrid Online Analytical Processing)

El HOLAP toma características del MOLAP y ROLAP. Una parte de los datos es almacenado en el motor de SSAS, los más recientes, para que sean accedidos de forma mas rápida, mientras que los restantes datos trabajan igual que ROLAP. Si se producen cambios en las tablas, la partición debe ser re-procesada.

2.4 - Ejemplo de particiones

Un breve ejemplo de cómo se podrían crear particiones usando diferentes filtros de tiempos (en este caso se usan rangos de meses), mostrando que los filtros pueden ser variables.

Tabla

Rango de años

Particiones

Tabla 1
(Measure Group)

2011

Particion A: Enero 2011 - Junio 2011

Particion B: Julio 2011 - Diciembre 2011

2012

Partición A: Enero 2012 - Junio 2012

Partición B: Julio 2012 - Diciembre 2012

Tabla 2
(Measure Group)

2013

Particion A: Enero 2013 - Marzo 2013

Partición B: Abril 2013 - Junio 2013

Partición C: Julio 2013 - Septiembre 2013

Partición D: Octubre 2013 - Diciembre 2013

3 - Agregaciones (Aggregations)

Las agregaciones se generan para mejorar los tiempos de respuesta de las consultas al cubo. Son parte de las particiones, ya que cada a cada partición tiene sus propias agregaciones.
Las agregaciones son datos pre-calculados y almacenados para distintos niveles del cubo. Una forma de verlas seria como usando un Group By en una consulta de SQL. Las agregaciones son calculadas al momento de procesar el cubo, por lo tanto a mayor número de agregaciones mayor va a ser el tiempo de proceso. Tener en cuenta que las agregaciones aumentan el tamaño en disco usado por el cubo.

3.1 - Diseño de Agregaciones

Aplica a los atributos con los que está relacionado esa partición.

Full

La agregación va a incluir el atributo seleccionado de la dimensión

None

Ninguna agregación va a incluir ese atributo

Unrestricted

El motor de SSAS va a decidir si el atributo va a ser incluido o no

Default

Cada atributo es evaluado por su granularidad, determinada en la dimensión.
Los atributos usados en jerarquías creadas por el usuario son tratados como "Unrestricted"
Los atributos que forman parte de una relación Many-to-Many, son tratados como None
El resto de los atributos es tratado como None

3.2 - Aggregation Options

A la hora de setear las agregaciones, existen 4 opciones:

Estimated Storage reaches

Crear cierto número de agregaciones hasta que alcanza un tamaño (MB)
estimado por el usuario, esto es almacenado en disco

Performance Gain Reaches

Estimar el % de ganancia que se quiere obtener a al usar agregaciones,
ese % aplica a la hora de usar esa measure, debe ser estipulado por el usuario.
Tener en cuenta que este porcentaje es estimativo

I click Stop

El motor crea agregaciones hasta que el usuario le diga lo pare

Do not desing Aggregations

No se diseñan agregaciones

4 - Ejemplo

Este ejemplo está basado en la Adventure Works 2012 que proporciona Microsoft de forma gratuita.

1) Ir a la solapa de "Partitions" y clickear en "New Partition"

clip_image002

2) Seleccionar la tabla sobre la que se quieren crear particiones.

clip_image003

3) Especificar el query para dividir las particiones

clip_image004

4) Determinar el nombre de la partición

clip_image006

5) Diseño de agregaciones:

clip_image007

6) El motor cuenta el número de filas que tiene esa partición

clip_image009

7) Opciones de agregaciones.

clip_image010

4 - Enlaces

AdventureWorksDW Database: Link

AdventureWorks SSAS: Link (seleccionar "AdventureWorks Multidimensional Models SQL Server 2012")

SQL Server 2008 Analysis Services Performance Guide: Link

 

¡Gracias por tu contribución Andrés Bernardo!

martes, 30 de septiembre de 2014

La sutileza del testing

En muchas ocasiones al integrarnos a un equipo de trabajo y presentarnos como testers del proyecto se nos puede llegar a ver como los verdugos que vienen a destruir el trabajo de desarrolladores o que se intenta evidenciar los errores en el código, sin embargo, es necesario que hagamos notar que somos parte del equipo y no buscamos evidenciar nada ni a nadie, solo buscamos elevar lo más posible la calidad del producto con el apoyo de los demás integrantes del equipo

Para realizar el reporte de resultado de las pruebas nos vemos en la necesidad de reportar los issues o defectos y que por más que mencionemos que son “del producto” terminan siendo identificados con el nombre de algún desarrollador a cargo.

Esto se intensifica si nos encontramos trabajando en outsourcing, asignados a un equipo probablemente con cliente, en donde muchas veces se nos ve como los extraños del grupo que solo vienen a criticar el trabajo. Por eso es importante tener una actitud que ayude a la integración con el equipo logrando así un impacto positivo a futuro ya que dará lugar a un buen desempeño y una buena prestación del servicio al cliente.

A continuación se listan y definen algunas características y actitudes que pueden ayudarnos y facilitar el trato con el cliente y con los equipos que conformen el proyecto.

Proactividad

De la misma manera en que nosotros estamos buscando la solución a alguna duda o problema en el que nos encontramos, se encuentran los demás integrantes del proyecto; por tanto debemos buscar la forma de aminorar tiempo y esfuerzo en la resolución de los mismos: investigando, pidiendo ayuda, realizando preguntas concretas a otros integrantes del equipo, etc.

Nunca debemos quedarnos sentados esperando a que alguien venga y nos de la solución a nuestras dudas, eso probablemente no sucederá, nos tomará una mayor cantidad de tiempo y nos hará ver perezosos y desinteresados.

Integración con el equipo

Debemos lograr sentirnos dentro del equipo de trabajo y que el resto de los miembros nos identifiquen como parte de él. Podríamos intentar buscar a las personas para tratar alguna duda o revisión de algún issue de forma presencial y no solo por correo, generar propuestas, y tener la iniciativa. Además no hace daño un poco de interacción extra laboral con los compañeros; como salir a comer, participar en fiestas de cumpleaños, algún after, etc.

Conocer el producto.

Hacernos y sentirnos parte del equipo, nos facilitará ser parte también en la construcción de ese producto y esto es un gran aporte a la calidad del mismo. Por ese motivo, se debe tornar desde el foco “destructivo” del testing (intentando rápidamente quebrar el producto en cuanto a su funcionalidad y rendimiento), al foco de “despojar de errores y mejorar la calidad”. Si bien el trabajo es el mismo, y la intensidad también es la misma, este último enfoque es el más adecuado para interactuar con las personas que están construyendo un producto, sean desarrolladores, arquitectos o gerentes de tecnología, entre otros. En nuestras interacciones interpersonales se notará que nosotros de alguna manera “queremos” al producto y estamos preocupados por la presencia de incidentes en él. Nuestra retribución personal ante el hallazgo de incidentes cambia de ser cazadores voraces de los más grandes y mejores bugs, para luego de reparados mejorar la calidad del producto; sino es el encontrar incidentes, lo antes posible, antes de que los usuarios finales los encuentren, y ver el producto, también “nuestro” producto, mejorando su calidad gracias a nuestro trabajo. Y este es uno de los puntos más importantes que quiero destacar.

Comunicación efectiva

No importando el medio de comunicación (correo electrónico, por teléfono o personalmente), debemos ser claros y concisos en los que deseamos dar a conocer. Una buena práctica es resumir la información en forma de esquema y de ser necesaria alguna explicación extra o dar a notar algún dato importante deberíamos resaltar las partes en negrita, utilizar estilos, tabulación, tablas, y colores (sin crear un arcoíris).

No olvidar que le descripción de los defectos o issues encontrados debe ser clara, proveer los pasos a seguir para la reproducción de los mismos; si es necesario mencionar características especiales que pueden forzar la reproducción del mismo (S.O, versión de explorador, datos e insumos utilizados, etc) y adjuntar evidencias del issue con el mayor detalle posible.

Por último no debemos olvidar cuidar que en los estatus se mantengan actualizados los issues, riesgos, limitantes que aún faltan por atender, los que ya han sido cerrados; e indicar la prioridad de los mismos.

Espero que lo anterior les sea de utilidad J

martes, 16 de septiembre de 2014

Certificar en ITIL

¿Queres certificar ITIL V3 Foundation?

En el campus vas a encontrar toda la información que necesitas para poder dar la certificación de ITIL v3 foundation!!!!

Tendrás acceso al material que dictan dos consultoras muy importantes (IAAP y Xelere) sin necesidad de asistir ni pagarlo, sino que lo podrás leer on line y tener toda la información que se requiere para poder certificar!!

También encontraras preguntas de examen típicas las cuales, una vez leído el material, te ayudaran a evaluar si estás preparado para rendir el examen.

¿¿¿Estás listo para empezar??? Continúa leyendo más sobre ITIL…

A continuación podrás encontrar algunas preguntas y respuestas que te ayudaran a entender que es ITIL, para que sirve y los niveles de certificación.

…Y que es ITIL y para qué sirve?

ITIL (Information Technology Infrastructure Library), es un conjunto de conceptos y prácticas para la gestión de servicios de tecnologías de la información, el desarrollo de tecnologías de la información y las operaciones relacionadas con la misma en general.

ITIL da descripciones detalladas de un extenso conjunto de procedimientos de gestión ideados para ayudar a las organizaciones a lograr calidad y eficiencia en las operaciones de TI. Ha sido desarrollada para servir como guía que abarque toda infraestructura, desarrollo y operaciones de TI. 

¿Cuantos niveles de certificación hay y en qué consisten?

ITIL V3 considera cuatro niveles de certificación:

  1. Nivel Inicial: Foundations. Asegura el entendimiento de los principios, la terminología y el contenido de los procesos y funciones considerados en ITIL V3.
  2. Nivel intermedio. Diseñada para reforzar las habilidades para analizar y aplicar los conceptos de ITIL. Existen varias opciones:
    • 5 de ciclo de vida de los servicios (estrategia de servicios, diseño de servicios, transición de servicios,  operación de servicios y mejora continua de servicios).
    • 4 de Capacidad (Soporte y análisis operacional -OS&A-, oferta y acuerdos de servicios -SO&A-, liberación, control y validación -RC&V- y planeación, protección y optimización -PP&O-).
  1. ITIL Expert. Destinada a aquellos que requieren consolidar el conocimiento obtenido en los niveles de certificación anteriores.
  2. ITIL Master. Es el nivel máximo de certificación en V3 y se enfoca en asegurar la habilidad para analizar y aplicar los conceptos de ITIL en nuevas áreas. Aún está en desarrollo.

¿Qué es ITIL foundation?

Este nivel es adecuado para personas que requieren una comprensión básica del marco de trabajo de ITIL y cómo puede usarse para mejorar la calidad de la gestión de servicios de TI dentro de una organización. También se aplica a profesionales de TI que trabajan para una organización que ha adoptado ITIL y por lo tanto necesitan estar al corriente y contribuir al programa de mejora general del servicio.

¿Por qué ITIL Foundation?

  • Enfoca el negocio y resuelve problemas de TI con las buenas prácticas en ITIL Foundation
  • Optimiza la comunicación entro los empleados de TI y sus clientes
  • Incrementa el valor de los servicios de TI alineándolos a las necesidades del cliente y los objetivos del negocio de ITIL Foundation
  • Fomenta un aumento en productividad a través de una inversión enfocada en conocimientos y experiencia
  • Con ITIL Foundation optimiza recursos y reduce costos en la provisión y el soporte de los servicios a través de la mejora continua.
  • Certifica a los profesionales de TI sentando las bases para una certificación ISO/IEC 20000 para la organización
  • Minimiza riesgos operativos y de TI con ITIL Foundation

¿Tenes dudas?

Podes contactar a las siguientes personas:

- Damián Villamea (LCP Comunidad ITX)

- Mariana Rube

- Leonardo Rosso.

 

¡¡¡Gracias por su contribución Mariana Rube y Leonardo Rosso!!!

martes, 9 de septiembre de 2014

A/B testing: ¿Qué es y para qué se utiliza?


Las pruebas A / B es la comparación de dos versiones de una misma página web para saber cuál funciona mejor. Básicamente se trata de verificar dos páginas, mostrando diferentes formas de la mismas, llamémosla A y B, para poder determinar ante cual los usuarios responden mejor. Lo que se intenta comprobar es qué versión tiene mejor desempeño, cambiando uno o varios elementos del diseño para saber cómo se comportan los usuarios.

También puede ser utilizado cuando queremos realizar un rediseño de un sito y no sabemos cómo los usuarios se comportaran ante el cambio de diseño, ya que se pueden sentirse perdidos o al contrario sería más sencillo llegar a algún elemento. Asimismo, si nos estamos anunciando en algún sitio podemos enviar a los usuarios aleatoreamente a las distintas versiones para saber cuál de ellas tiene mejor conversión en donde podríamos cambiar los colores de fondo, la posición de los elementos, el formulario de contacto, etc.

Para todo tipo de prueba existen ventajas y desventajas, para el caso del A/B test son las siguientes:

Ventajas:

ü Fácil de usar y comprender: se deberá crear diferentes versiones y ver cuál es la que mejor funciona.

ü Fácil de analizar: simple para comprender los resultados.

ü Flexibilidad: se pueden plantear los cambios que se consideren oportunos en las distintas versiones para probar.

ü Menor volumen de información necesaria: las conclusiones se pueden alcanzar con un volumen de datos menor.

Desventajas:

ü No nos dice, por sí solo, cuál es el elemento que causa un mejor o peor desempeño de la conversión.

ü Puede darse el caso de que un elemento mejore la conversión y otro la empeore siendo el resultado que no hay mejora con respecto al original.

Cuando utilizamos el A/B testing se deberían testear funcionalidades tales como:

- Botones o “call to action”

- Diferentes recorridos de navegación

- Las páginas que tiene mucho trafico

- Diferentes tipos de diseño

Existen varias herramientas para poder llevar a cabo un test de A/B alguna de las principales herramientas son:

Google Analytics: es una herramienta gratuita que se puede analizar hasta el más mínimo detalle de la web y, lo que es más importante, se puede conocer el comportamiento de tus usuarios cuando la visitan.

Crazy Egg: es una de las herramientas más sencillas de utilizar al igual que Google Analytics. Crea mapas de color en la web en base al comportamiento de los usuarios en cada visita. Con ella se podrá saber dónde se mueven los usuarios cuando entran a la web.

Mixpanel: es una manera diferente y más sencilla de aproximarse al mundo de la analítica web. Incluye funciones de marketing online.

KISSmetrics: está enfocada a las acciones de los usuarios y está orientada a la parte comercial.

Optimizely: se pueden crear test A/B de manera más sencilla, además se pueden crear diferentes versiones rápidamente, analizando los resultados y eligiendo la mejor versión de todas.

 

¡Gracias por tu contribución Eugenia Spadaro!

miércoles, 3 de septiembre de 2014

Desarrollo rápido con Azure DocumentDB

Por Fernando Hunth

 

DocumentDBAzure DocumentDB es un nuevo servicio de base de datos documental NoSQL diseñada para apoyar de forma nativa JSON y JavaScript directamente en el interior del motor de base de datos. Es una solución ideal para las aplicaciones web y mobile cuando las claves de esa aplicación son el rendimiento , la baja latencia y consultas flexibles. Actualmente aplicaciones como OneNote ya utilizan DocumentDB para soportar millones de usuarios.



enables-rapid-developmentAzure DocumentDB te permite un desarrollo rápido reduciendo la fricción y la complejidad en la construcción de nuevas aplicaciones de negocio mediante el acceso a bases de datos a través de CRUD, consulta y procesamiento de JavaScript a través de una sencilla interfaz HTTP RESTful . Programar contra DocumentDB es simple , accesible , abierto y no requiere codificación o extensiones personalizadas para JSON o JavaScript .
 


Para mas información sobre este tema:


martes, 2 de septiembre de 2014

TFS - Evitar checkout automático y editar archivos bloqueados

Cuando deseamos hacer pruebas en nuestra aplicación sin la necesidad de bloquear algún archivo o necesitamos editar parte del mismo cuando está bloqueado por otro desarrollador, es útil configurar Visual Studio de la siguiente manera:

[Pasos]

1. En Visual Studio, dentro del menú Tools, click Options.

2. En el cuadro de dialogo de Options, click Source Control, y luego click Environment.

clip_image002

[Ventajas]

Varias veces nos sucede que queremos editar archivos bloqueados por otro desarrallador, ya sea para hacer una prueba, o comentar un proceso existente. Esto nos permite editarlo y probarlo, sin tener que hacer un check-out del archivo.

Por ejemplo, esto ocurre muy seguido con los archivos de configuración de acceso a servidores: web.config. Es común el caso de que varios desarrolladores quieran compilar el código junto con el archivo de configuración apuntando a distintos servidores de datos cada uno.

[Contras]

Si no se trabaja de forma organizada, cualquier distracción puede generar que se pierdan los cambios subidos por otros desarrolladores, al trabajar simultáneamente sobre el mismo archivo.

¡¡¡Gracias Hernán Lavrencic por tu contribución!!!

miércoles, 27 de agosto de 2014

Bajate los videos de las 38 sesiones de dotnetConf 2014

 

 

Si te perdiste el dotNetConf 2014 aca tenes una lista de todas las sesiones para bajartelas o verlas en Channel9

1. Taking Your ASP.NET Apps to the Cloud with Microsoft Azure Web Sites

2. Entity Framework

3. New Innovations in .NET Runtime

4. The Future of C#

5. Building Universal Windows Apps with XAML and C# in Visual Studio

6. .NET Native Deep Dive

7. Fun with .NET - Windows Phone, LEGO Mindstorms, and Azure

8. Developing Native iOS, Android, and Windows Apps with Xamarin

9. ASP.NET vNext 101

10. SignalR

11. ASP.NET Identity

12. ASP.NET Publishing Explained

13. ASP.NET Web Forms

14. What's new for WPF Developers

15. ASP.NET Today and Tomorrow (Keynote)

16. Dependency Injection and Testability in .NET

17. What's New in XAML Platform & Tooling

18. State of .NET (Keynote)

19. Kinect for Windows

20. ASP.NET MVC 6 (now with integrated Web API!)

21. New Innovations in .NET Runtime

22. The Future of C#

23. Building Universal Windows Apps with XAML and C# in Visual Studio

24. .NET Native Deep Dive

25. Fun with .NET - Windows Phone, LEGO Mindstorms, and Azure

26. Developing Native iOS, Android, and Windows Apps with Xamarin

27. ASP.NET vNext 101

28. SignalR

29. ASP.NET Identity

30. ASP.NET Publishing Explained

31. ASP.NET Web Forms

32. What's new for WPF Developers

33. ASP.NET Today and Tomorrow (Keynote)

34. Dependency Injection and Testability in .NET

35. What's New in XAML Platform & Tooling

36. State of .NET (Keynote)

37. Kinect for Windows

38. ASP.NET MVC 6 (now with integrated Web API!)

Para bajartelas todas dale una Mirada a este script. Para ver los videos en Channel9, click aqui.

 

Fernando Hunth

viernes, 22 de agosto de 2014

Diseño de diagramas con herramienta para presentaciones con profundidad escalable – Prezi

Una forma fácil de hacer presentaciones con gran cantidad de detalles y al mismo tiempo, tener la posibilidad de realizar muestras superficiales o de forma generalizada, gracias a los múltiples niveles de zoom.

[Capturas]

clip_image002
http://prezi.com/fpkvo7he2ls3/guia-uml-adsi-30/
clip_image004

[Ventajas]

Permite generar una presentación tanto a nivel funcional, como a nivel técnico y arquitectónico, gracias a la escalabilidad, que brinda la opción de tener una versión superficial / funcional del proyecto, y al mismo tiempo, la opción de poder profundizar en aquellos puntos donde sea necesario revisar asuntos técnicos importantes.

Permite realizar reuniones con el grupo técnico y funcional al mismo tiempo, integrando de forma continua los conceptos en una única presentación.

Aplicación online y offline que permite el trabajo simultáneo y cooperativo de varias personas sobre una misma presentación.

[Contras]

La versión gratuita tiene capacidad de almacenamiento limitada y los trabajos almacenados son públicos.

miércoles, 6 de agosto de 2014

Diseñar y Programar Pensando en el Cambio

¡Hola! Hoy quería compartir con ustedes mi experiencia, sobre todo técnica, en el manejo de los Pedidos de Cambios que se dan en los Proyectos de Desarrollo de Software. Fundamentalmente, sobre cómo diseñar y programar una Aplicación para que no se hunda en el caos absoluto ante el primer Pedido de Cambio que debamos implementar sobre la misma.

 

Primero y Antes Que Nada… ¿Qué es un Cambio?

 

clip_image002[4]

Según la Real Academia Española (RAE), un Cambio puede definirse como la “Acción y efecto de cambiar”. Bien, entonces nos preguntamos, ¿qué es cambiar? Pues bueno, también según la RAE, Cambiar puede definirse como “Dejar una cosa o situación para tomar otra”.

Si bien ésta es una buena aproximación teórica, aún dista bastante del concepto que tenemos en nuestra profesión acerca de lo que es un cambio.

En el mundo del Desarrollo de Software, lo solemos entender de otra forma: un Cambio es un pedido, generalmente formal, que suele realizar el Cliente y a través del cual solicita modificar un Requerimiento previamente definido, o bien añadir uno nuevo al Backlog de Tareas, de acuerdo a un conjunto de necesidades, correcciones, mejoras y/o restricciones que hayan surgido a posteriori de haber relevado y acordado el Requerimiento original.

 

El Proceso de Gestión de Cambios

Teniendo en mente el Proceso de Gestión de Cambios y de cómo construir aplicaciones con una mayor flexibilidad para incorporar cambios, vale la pena aclarar algo: al desarrollar Software, siempre estará latente la posibilidad de que surjan modificaciones en el transcurso del Proyecto, ya que los Requerimientos, como toda necesidad, distan mucho de permanecer estáticos en el tiempo.

No podemos negar esta realidad, pero sí podemos estar preparados para gestionarlos de la mejor forma posible y ser conscientes de la necesidad de diseñar una aplicación que sea robusta y permeable a los cambios con el objetivo de minimizar los impactos negativos que estos pudieran ocasionar en otras áreas o módulos de la misma.

Retomando la definición que habíamos presentado en el punto anterior, cada uno de estos pedidos que nos suelen llegar de nuestros Clientes, los cuales pueden ser formales o no tanto (a veces sucede que el Cliente no los manifiesta explícitamente o lo hace por vías informales, como por ejemplo, en una charla de pasillo), los solemos conocer como “Solicitudes de Cambio” o “Pedidos de Cambio”, y están soportados por un procedimiento formal, estructurado y bien documentado que permite gestionar los diferentes estadios de los cambios, desde que los mismos se originan hasta que son cerrados o descartados. Este procedimiento lo solemos conocer como Proceso de Gestión de Cambios.

A grandes rasgos, y sin entrar en detalles en lo que es la Gestión de Proyectos, podemos identificar las siguientes etapas dentro de lo que es el Ciclo de Vida de un Pedido de Cambio:

· Registración del Pedido de Cambio

· Realización de un Análisis de Impacto (de gestión, funcional y técnico)

· Negociación y Acuerdo del Pedido de Cambio con el Cliente

· Aprobar, rechazar, modificar o posponer la Implementación del Pedido de Cambio

· Desarrollo e Implementación del Pedido de Cambio, en el caso de que el mismo sea aprobado

· Validación y Verificación del correcto funcionamiento de la Aplicación, tomando como punto de partida el Análisis de Impacto realizado previamente

Es imprescindible, en el caso de que un Pedido de Cambio sea aprobado, que el mismo sea comunicado a todos los miembros del equipo involucrados en el proyecto, de forma que estén al tanto del asunto, ya que puede suceder que deban revisarse otros módulos de la Aplicación, o que haya que cambiar un estándar o simplemente que genere incompatibilidades con algo que ya tenemos hecho.

Si el equipo no es notificado oportunamente, va a seguir trabajando con supuestos que puede que ya no sean válidos y que eventualmente como consecuencia se produzcan más cambios en cadena en un futuro no muy lejano.

 

¿Con Qué Tipos de Cambios Podemos Encontrarnos?

clip_image004[4]Determinar todos los cambios posibles que podrían surgir en un proyecto dado es algo inviable, ya que, por un lado, deberíamos conocer al mínimo detalle las especificaciones funcionales y no funcionales del proyecto; y por el otro, el Cliente, el Usuario y todos los involucrados en el Proyecto deberían tener identificadas absolutamente todas sus necesidades y mantenerlas estáticas a lo largo del tiempo.

No obstante, lo que sí podemos conocer y determinar son las diferentes dimensiones que poseen los cambios, lo cual nos va a servir para catalogarlos, preverlos y gestionarlos en el transcurso del proyecto. De todas las dimensiones que existen, en este artículos nos vamos a centrar únicamente en tres de ellas: los Orígenes, los Motivos y los Tipos de Pedidos de Cambios, las cuales nos van a proveer ciertas pautas que deberemos tener en cuenta a la hora de diseñar y programar una solución pensando en los cambios.

En lo que respecta a la dimensión Orígenes de los Pedidos de Cambios, podemos encontrar las dos siguientes fuentes:

· Internos, que es cuando los cambios surgen dentro del mismo Equipo de Desarrollo de la Aplicación. En estos casos, no siempre se lo suele involucrar al Cliente.

· Externos, que es cuando los cambios son planteados por el Cliente, el Usuario Final o algún Área vinculada al proyecto (como por ejemplo los Departamentos de Arquitectura, de Seguridad o de Change Management).

Por otro lado, en la dimensión Motivos de los Pedidos de Cambios solemos encontrar tres razones que pueden dar surgimiento a los cambios:

· Nuevas Necesidades y/o Restricciones, que no se hayan contemplado en el relevamiento inicial de los requerimientos, y que generalmente serán planteadas por el mismo Cliente o el Usuario Final.

· Mejoras, producto de ajustes que haya que realizarle a la Aplicación en pos de mejorar el rendimiento de la misma, la usabilidad por parte del usuario, la interacción con otros sistemas, etc.

· Correcciones, originadas principalmente por errores en la Especificación y/o en la Construcción de la Aplicación. Comúnmente los solemos conocer con los nombres de Bugs, Issues o Incidentes.

Y por último, podemos encontrar la dimensión Tipos de Pedidos de Cambio, que suele estar más asociada al impacto que un cambio genera en los requerimientos originales:

· Pedidos de Cambios Funcionales, los cuales están asociados a los Requerimientos Funcionales de la Aplicación, es decir, a las funciones que debe realizar la Aplicación, al comportamiento interno que debe tener el Sistema.

· Pedidos de Cambios No Funcionales, los cuales están asociados a los Requerimientos No Funcionales, más que nada a los Atributos de Calidad del Software. Si bien hoy en día aún existen algunas discrepancias entre los diferentes referentes del tema, a grandes rasgos podemos encontrar las siguientes subcategorías de Requerimientos No Funcionales: Funcionalidad, Flexibilidad, Usabilidad, Eficiencia, Mantenibilidad y Portabilidad.

 

¿Cómo Hacer Que Mi Aplicación Sea Más Permeable a los Cambios?

Entonces, tomando en cuenta todo lo anterior, desde nuestra perspectiva más técnica ¿existe algo que podamos hacer, ya sea en el armado de la arquitectura, en el diseño de un módulo o en la programación de una funcionalidad, para que al llegar un Pedido de Cambio se minimice el impacto negativo de su implementación?

Definitivamente, la respuesta es sí. Sí podemos tomar acciones tempranas que nos ayuden a diseñar y construir una Aplicación preparada para recibir cambios en un futuro; es decir, que sean flexibles a las modificaciones y robustas en el sentido de que dicha Aplicación no se rompa al tener que alterar una funcionalidad o módulo de la misma.

A continuación, vamos a enumerar algunas recomendaciones que podremos tener en cuenta en las diferentes etapas de diseño y construcción de una Aplicación para que, llegado el momento de tener que implementar uno o más cambios, logremos mitigar el riesgo y reducir el impacto negativo de la tarea:

· Como primer punto, al pensar y diseñar la Arquitectura de la Solución, deberemos tener en cuenta que la misma tiene grandes probabilidades de ir sufriendo modificaciones conforme avancemos en el proyecto. Es fundamental que entendamos que la Arquitectura es dinámica, y que debe ser lo primero que sea adaptable al cambio en un Sistema.

· Consensuar la Arquitectura con el equipo de trabajo, y si lo hubiera, también con el equipo técnico del Cliente. De esta forma nos vamos a asegurar de tener un mejor diseño de entrada, antes de comenzar con el grueso de las tareas de construcción de la Aplicación.

· Siempre se deberá plantear la Solución de forma Modular, identificando las diferentes Áreas de la Aplicación y tratar de lograr un bajo acoplamiento entre áreas independientes. Si hubiera que integrar una o más áreas, una buena técnica es utilizar Interfaces que nos abstraigan de los detalles de la implementación particular de cada una de ellas.

· Es importante identificar los Módulos Core de la Solución, que son aquellos que van a ser utilizados por el resto de los Módulos de la Aplicación (como por ejemplo los Módulos de Seguridad, Permisos, Logueo de Errores, Configuración, Exportación de Datos, etc.), y dotarlos de las interfaces necesarias para garantizar una buena integración sin exponer demasiados detalles de su implementación interna.

· Por otro lado, también es importante identificar las capas que van a formar parte de nuestra Aplicación (por ejemplo las Capas de Interfaz de Usuario, de Servicios de Negocio, de Acceso a Datos, etc.) y definir y comunicar las responsabilidades que cada una de ellas va a tener, de forma de organizar mejor el código y las funciones que se deberán construir.

· Vinculado al punto anterior, es sumamente importante que la lógica de negocio esté concentrada en un único lugar, llámese área, capa o módulo. Por ejemplo, si definimos que va a haber una Capa de Negocios, entonces sólo deberá haber Lógica de Negocio en dicha capa. Esto debe ser respetado por todo el equipo, ya que la Lógica de Negocio es el ítem que más Pedidos de Cambio deberá soportar a lo largo de un Proyecto. Lamentablemente es bastante común, especialmente en proyectos grandes, encontrar con el paso del tiempo Lógica de Negocio desperdigada por toda la Solución, lo que finalmente termina derivando en mayores esfuerzos y riesgos a la hora de tener que aplicar un cambio sobre determinada funcionalidad.

· Definir y comunicar estándares de construcción y codificación, de forma de mantener homogénea la Solución. Esto es importante ya que si un miembro del equipo debe aplicar un cambio en un módulo que él no programó, al menos el código y el estilo de construcción le resulte familiar y se minimice el riesgo de introducir errores.

· Ante cambios complejos o con un impacto alto, es recomendable agregar comentarios en el código que expliquen el por qué fue necesario el cambio y un resumen acerca de lo que se realizó. Si bien esto debería agregarse también en el Changeset, es más fácil y útil tenerlo a mano en el código por si es necesario realizar un ajuste posterior.

· Ya sea que estemos desarrollando una Aplicación Web o Desktop, es fundamental que hagamos una clara separación entre el Layout de las Pantallas y la lógica que les da soporte a las mismas. Si el ítem que suele sufrir mayor cantidad de Pedidos de Cambios es la Lógica de Negocio, el segundo lugar es para los Aspectos Visuales (Look & Feel) de la Aplicación. Es más sencillo y menos riesgoso hacer las modificaciones si los componentes se encuentran correctamente separados.

· Relacionado con lo anterior, por ejemplo, si estamos trabajando en una Aplicación Web, deberemos construirla desde un comienzo pensando en separar la estructura de las páginas (en los archivos HTML), de la forma en la que se van a visualizar (en los archivos CSS), y de la lógica de cliente que pudieran tener (en los archivos Java Script).

· En el caso de WPF, por citar un ejemplo, es posible emular el manejo de estilos trabajando con Resource Dictionaries e importarlos en cada una de las pantallas que conforman la Aplicación. Otras tecnologías modernas de Interfaz de Usuario también ofrecen alternativas que nos permiten desacoplar la lógica de la estructura de los aspectos visuales de las pantallas.

· Definir y utilizar una buena herramienta de Software Configuration Management (SCM), no sólo como repositorio de código fuente, sino también para gestionar el Ciclo de Vida de los Pedidos de Cambio. Una de las mayores ventajas es que al utilizar una única herramienta podremos lograr una trazabilidad entre Pedido de Cambio/Impacto/Modificaciones en la Aplicación que nos permitirán evaluar y corregir eventuales incidencias que se originen a futuro como consecuencia de la implementación de un cambio determinado.

· Si tenemos que implementar un Cambio con un Impacto alto, es una buena práctica hacerlo en un Branch aparte, de forma de mantener controlado el Impacto y no afectar al resto del equipo hasta que el mismo se haya implementado e integrado total y correctamente al resto de la Aplicación.

· Otra buena práctica, para asegurarnos que la implementación de un cambio no generará comportamientos no deseados en el actual funcionamiento de la Aplicación, será contar con un buen conjunto de Unit Tests, los cuales podremos ejecutar a demanda para verificar que todo siga funcionando correctamente luego de haber realizado las modificaciones.

· Extendiendo el concepto del punto anterior, aún mejor sería contar con Tests Automáticos y un Servidor de Integración Continua, para que de esta forma podamos validar en todo momento el estado de la Aplicación. Además, un buen Servidor de Integración Continua nos ofrecerá reportes, estadísticas, y nos avisará cuando algo falle en la Aplicación para que lo corrijamos inmediatamente antes de continuar con nuestras tareas.

Bueno, la anterior es sólo una pequeña lista con ideas que podemos tomar para lograr que nuestra Aplicación pueda incorporar cambios más fácilmente, armada desde mi experiencia y de lo que sugieren las Buenas Prácticas de Desarrollo de Software. Los invito a colaborar para completarla, proponiendo ideas que desde su experiencia nos ayuden a lograr aplicaciones más permeables a los cambios, flexibles y robustas.

Obviamente, si bien el hecho de tener en cuenta los puntos anteriores no nos va a garantizar el éxito al tener que implementar los cambios que vayan surgiendo en el proyecto, sí nos va a ayudar a mitigar los impactos negativos que pudieran llegar a ocurrir en este proceso.

Por último, y ya despidiéndome de ustedes quería dejarles un pequeño chiste de Dilbert, alegórico al tema central de este artículo. Espero que les guste J

clip_image006[4]

 

¡Gracias Ariel Bensussan por tu contribución!

jueves, 31 de julio de 2014

En testing también debemos gestionar los cambios


Por Nadia Soledad Cavalleri

Software Configuration Management (SCM) es una disciplina de la ingeniería de software que comprende el conjunto de actividades necesarias para identificar, administrar y controlar todos los elementos que constituyen un software, sus cambios y sus relaciones, definiendo mecanismos para gestionar las diferentes configuraciones y posibilitar la reproducción de cualquiera de éstas.

Cuando hablamos de SCM, en lo primero que tendemos a pensar, es en su aplicación a equipos, ambientes y prácticas de desarrollo. Probablemente, esto se deba a que SCM emergió como disciplina enfocada en la programación, sin cubrir otros aspectos del proceso de desarrollo de software. Pese a esto, debemos tomar dimensión de la importancia que SCM tiene en los equipos, ambientes y prácticas de testing.

Repasando estos tres aspectos, nos encontramos con que los equipos tradicionales de pruebas están conformados por diferentes roles, en general, un gerente o líder de pruebas, algunos analistas, diseñadores, automatizadores, testers, y por qué no, algunos otros colaboradores.

Cuando hablamos de ambientes de pruebas, nos referimos a las configuraciones y los artefactos. Entendiendo por configuraciones, al conjunto de hardware, software, base de datos, sistemas operativos, redes y permisos y, por artefactos, a los productos de las actividades, tales como, planes de prueba, casos de prueba, scripts, logs, mejoras, bugs y reportes.

Siguiendo las buenas prácticas de SCM, deberíamos identificar aquellos ítems propensos a cambiar. Todos los artefactos mencionados tienen esa cualidad ya que están fuertemente relacionados con productos de otras disciplinas, como análisis y desarrollo, que también cambian permanentemente. Por ejemplo, el plan de pruebas está directamente relacionado con el plan del proyecto, los casos de prueba dependen de los requerimientos o de la especificación de casos de uso, los script de pruebas y los logs de sus ejecuciones están asociados a una versión determinada del build así como los bugs son reportados y resueltos en versiones específicas. Entonces, si el plan del proyecto, las especificaciones y el software pueden cambiar ¿Por qué no va a cambiar su par asociado en testing?

A pesar de que la configuración parece la parte más estática, también es susceptible de cambios, por ejemplo, por la instalación de parches, la migración hacia diferentes versiones, la creación de usuarios, la asignación de roles, la modificación de permisos, etc. Todos estos son ejemplos de situaciones con las que nos topamos a diario y que evidencian que en testing también ocurren cambios y, por lo tanto, también hay que gestionarlos.

Pero SCM no implica solamente gestionar los cambios con un controlador de versiones. Su objetivo es un poco más ambicioso. Cuando hablamos de SCM también nos estamos refiriendo al trabajo en paralelo, a la posibilidad de restaurar configuraciones previas y a mantener la trazabilidad entre los artefactos, entre otras cosas.

La aplicación de todas estas prácticas es tan indispensable en testing como lo es en desarrollo. Por ejemplo, al probar, también trabajamos de manera concurrente, quizá porque mientras un miembro del equipo está diseñando un caso de prueba otro está ejecutando o quizá porque tenemos dos o más automatizadores que están desarrollando sus scripts al mismo tiempo. En este caso, los automatizadores comparten el código fuente utilizado para automatizar las pruebas de la misma manera que los desarrolladores comparten el código de la aplicación que están construyendo. Poder volver a una versión anterior, a nivel de configuración y no solo de código, también puede ser necesario si tenemos que reproducir un bug en la misma versión y configuración del software en la que fue detectado.

La trazabilidad no es un tema menor. Los productos de testing están asociados con productos generados por otras disciplinas. En el medio de los cambios, la trazabilidad es extremadamente importante porque nos permite mantener la integridad de los modelos, datos y documentación. Además nos ayuda a identificar unívocamente las pruebas asociadas a una versión de la aplicación o de cualquier otro artefacto.

Queda claro entonces que si reconocemos la importancia de SCM en los equipos, ambientes y prácticas de desarrollo debemos otorgarle el mismo peso a los equipos, ambientes y prácticas de testing porque tienen un modo similar de funcionamiento y, a pesar de que ambos equipos trabajen con diferentes artefactos, tienen que gestionar temas de similar envergadura.

lunes, 21 de julio de 2014

Certificación JAVA OCA SE 7

Una experiencia de certificación exitosa…

clip_image002La certificación es una manera efectiva de validar los conocimientos de una persona en un área específica. Certificarse le permite saber a nuestro empleador o futuro empleador que tenemos los conocimientos suficientes para poder operar una herramienta o administrar tareas. En este sentido, las certificaciones de Oracle son de las más valoradas en el mercado IT.

El roadmap de certificación en Java es muy amplio. Este documento se basa en la certificación de desarrollador Java, más específicamente en la certificación “Java OCA”.

En un sentido más amplio, el camino de certificación como desarrollador Java es el siguiente:

clip_image004

Estas certificaciones son conocidas también como:

clip_image006

Los temas del examen pueden ser consultados en los links de más abajo.

Diseño del examen

El código del examen es 1Z0-803, está en inglés, consta de 90 preguntas y tenemos 150 minutos para resolverlo (2 horas y media). El porcentaje de aprobación es de 63% (hace unos meses era de 77%), son 57 preguntas que deben estar correctas.

Las preguntas son del tipo Multiple-choice y si hay más de una opción verdadera y no la elegimos, toda la pregunta se considera errónea.

En la página del examen figura el precio.

Guía para certificarse

1) Conseguir el material de estudio.

2) Estudiar ;)

3) Comunicarle al tutor nuestra intención de certificarnos.

4) Presentarse a rendir.

5) Obtener la nota.

1) Conseguir el material de estudio.

Oracle nos provee de una guía oficial de estudio: “OCA Java SE 7 Programmer I Study Guide (Exam 1Z0-803) (Oracle Press)”.

En la biblioteca de Baufest está disponible la guía para ser consultada.

En la guía están identificados todos los temas del examen, con una explicación un tanto resumida. Personalmente lo encontré muy teórico y poco abarcativo.

Yo recomiendo especialmente los simuladores de exámenes (mock exam), hay varios trials para bajar (en la guía de estudio figuran varias urls), yo decidí comprar el de Enthuware: http://enthuware.com/index.php/mock-exams/oracle-certified-associate/java-programmer-certification-i

Viene con 584 preguntas y la justificación de las respuestas, de ahí saqué un montón de información importante.

Una de las falencias que encontré en la guía de estudio oficial es que no ahonda en todas las posibles combinaciones del uso de alguna característica del lenguaje.

Por ejemplo, algo bien básico que nos puede hacer equivocar, la declaración del método main, es: 

public static void main( String[] args), pero qué pasa si en vez de main ponemos Main?, bueno, eso es perfectamente válido. Va a compilar. Sólo que no es el mismo método main que se ejecuta cuando se ejecuta la clase, pero es válido. También es válido agregarle la palabra "final" adelante. Y esas cosas la guía no lo dice.

En fin, el simulador de examen es de un nivel difícil, pero nos asegura ir mejor preparados. En las simulaciones que hice, no saqué más del 71% y promedié un 66%, sin embargo en el examen había preguntas más fáciles que las del simulador. También había preguntas iguales, a tal punto que hasta el nombre de las variables era iguales a las del simulador.

Una cosa que me sorprendió es que en el examen real había muchas preguntas sobre arrays, cómo declarar múltiples dimensiones, etc. y en el simulador no hacían mucho hincapié en eso.

Y algo muy tedioso pero necesario, es estudiar el tema de las excepciones, había muchas preguntas sobre eso también.

Hay que tener en cuenta la precedencia de los operadores, y conocer las funciones posibles de String, StringBuilder, y las de ArrayCopy por ejemplo.

2) Estudiar ;)

3) Comunicarle al tutor nuestra intención de certificarnos.

En Baufest contamos con el rol “Tutor”, es una persona con experiencia en la empresa que nos asesora sobre diversos temas. Nos muestra el camino. En ese sentido, mi tutor se ocupó de hablar con “Desarrollo Profesional” quienes gestionaron el voucher para poder rendir. Me dijeron el día y la hora y me presenté en Buffa. Recomiendo ir con tiempo para poder repasar.

4) Presentarse a rendir.

Rendí el examen en Buffa sistemas http://www.bs.com.ar/ Es un instituto de sistemas donde además, tienen un acuerdo con Pearson VUE que es el que organiza las certificaciones de Oracle.

En este caso, vino la persona encargada de los exámenes, me hizo el check-in en Oracle, esto es, me sacó una foto y me hizo firmar una planilla.

Tuve que guardar la mochila, campera y celular en un armario.

Luego, me dirigí al "aula" donde había dos computadoras, el aula era muy chica, había lugar para sólo dos personas.

Preparó la máquina y empezó el examen.

El programa es bien básico, obviamente una vez iniciado no deja minimizarse ni abrir notepad ni calculadora. Para hacer las anotaciones me dieron unos "blocs borradores”: un papel oficio plastificado y un marcador para escribir arriba.

El programa nos va diciendo el número de pregunta en la que estamos y la cuenta regresiva del tiempo. Las preguntas que nos generan dudas las podemos marcar con una "x" y al final, se pueden revisar rápidamente.

Para pasar de pregunta demora unos dos segundos, así que si estás en la número 2 y querés revisar lo que pusiste en la 70, tenés que ir de una en una y lleva su tiempo.

5) Obtener la nota.

Una vez finalizado el examen, aparece una pantalla que nos dice que el resultado va a estar disponible dentro de 30mins. Pasado ese tiempo, nos llega un mail donde figuran las instrucciones para poder ver el resultado, esto significa que vamos a tener que entrar a education.oracle.com, registrarnos y verificar la cuenta por mail, luego hacer login y entrar a una opción que dice "New exam results", donde va a figurar el resultado del examen. Simplemente nos va a decir nuestro score, el mínimo de 63% para aprobar, nuestra foto, alguna información como el día, ids, etc. Y los "temas" en que nos equivocamos.

El certificado electrónico final está disponible luego de unas 48hs y el físico hay que pedir que lo manden por mail.

clip_image008

Certificado electrónico.

Links útiles:

  • JAVA OCA: http://education.oracle.com/ y poner en el buscador “Oracle Certified Associate, Java SE 7 Programmer”. Elegir el primer resultado que aparece.
  • JAVA OCP: http://education.oracle.com/ y poner en el buscador “Oracle Certified Professional, Java SE 7 Programmer”. Elegir el primer resultado que aparece.

Material de estudio:

Baufest valora la capacitación formal de sus profesionales, por eso apoya las certificaciones con beneficios sobre los exámenes y el cursado de los cursos. Además ofrece un Plan de certificaciones.

Autor:

clip_image010
Julián Haeberli

jueves, 17 de julio de 2014

9 tips para armar un buen plan de pruebas

Ya sea que debas crear un plan de pruebas por primera vez o seas un tester experto, nunca está de más recibir algunos consejos. A continuación, 9 consejos que nacen de la experiencia de haber hecho muchos planes de prueba en variados proyectos:


  • (1) Usar un template es bueno, pero ¡el template no está hecho en piedra!

Es muy útil usar un template de Plan de pruebas como guía pero no hay que aferrarse a rajatabla a la estructura propuesta. Los proyectos informáticos son muy variados y no existe el template universal. El template sirve como ayuda pero el índice lo determinará finalmente la información de la que necesitemos disponer para guiar el proceso de testing a lo largo del proyecto.

  • (2) El plan de pruebas no es el cronograma de tareas

Muchas personas confunden un plan de pruebas con dar un calendario de cuándo se ejecutarán las pruebas y de cuánto tiempo llevarán. El cronograma de las pruebas es una parte del plan pero el plan es mucho más que solo el calendario. El plan contiene adicionalmente información sobre qué actividades se realizarán como parte del proceso de testing, qué objetos serán ítems a testear, qué estrategias se aplicarán, que tipos de pruebas se harán, como así también deja explicitado qué aspectos quedarán fuera del proceso de testing y por qué. Esta información determina una estrategia general que guiará el proceso de pruebas a lo largo del proyecto y que no debería cambiar demasiado en el transcurso del mismo. El cronograma de las pruebas, por otro lado, muy probablemente sufrirá modificaciones durante el proyecto.

  •  (3) Listar explícitamente cuales son las actividades dentro del alcance del plan es tan importante como listar cuales estarán fuera del mismo.

Lo más probable es que las actividades clásicas de un proceso de pruebas, como ser el diseño de casos, la ejecución de pruebas funcionales, registración de su resultado, registración de los issues/bugs, su comunicación y seguimiento, estén dentro del alcance. Pero algunas actividades relacionadas al aseguramiento de la calidad, como ser la revisión de artefactos del proyecto (casos de uso, especificaciones, documentos de arquitectura, etc.) podría o no estar contemplada. Así mismo como las actividades de automatizar la ejecución de las pruebas, o de actualizar/generar el material de soporte, o de participar del monitoreo de issues/bugs luego del despliegue en producción, por ejemplo. Indicar explícitamente en el documento de plan de pruebas cuales actividades formarán parte del alcance y enumerar cuáles no, provee un marco para dimensionar el esfuerzo que requerirá el proyecto y permite manejar correctamente las expectativas del cliente.

  •  (4) La naturaleza del proyecto guiará el diseño de las pruebas

Desde el punto de vista del alcance de los objetos a probar (¿qué se testeará?) y del alcance de las pruebas (¿qué tipos de pruebas se ejecutarán?) no es lo mismo un proyecto de migración/upgrade que un proyecto de mantenimiento o agregado de funcionalidades que un proyecto donde se construye un software de cero. Más aun, dos proyectos de la misma naturaleza no necesariamente se testearán de la misma forma. El plan de pruebas debe estar alineado al plan de proyecto: después de todo ¡estamos trabajando en el mismo proyecto! y muchos aspectos intrínsecos del proyecto determinan aspectos relacionados a la planificación de las pruebas. Este análisis es parte de la actividad de planificar las pruebas y sus justificaciones deben quedar escritas en el plan de pruebas.

  •  (5) Es importante conocer el landscape del proyecto y como se administrarán los despliegues al momento de planificar los ciclos de prueba

Cuando pensamos en las actividades del proceso de pruebas, pensamos por ejemplo en la de ejecutar las pruebas. Sin embargo tenemos que recordar que esta actividad se repetirá muchas veces a lo largo del tiempo. Potencialmente tendremos una ejecución con cada despliegue. Es por ello que para poder calendarizar las pruebas o dar un cronograma probable debemos conocer ¿cuántos ambientes componen el landscape del proyecto? ¿En cuáles se ejecutarán pruebas? ¿Cómo se administrará el despliegue de las correcciones que hagan falta hacer? No es lo mismo un proyecto con varios ambientes de desarrollo locales que deben mergearse (en otro ambiente) para luego pasar a un ambiente de calidad interno para luego pasar a uno de pre-producción del cliente para finalmente llegar a producción, que un proyecto con un ambiente de desarrollo, uno de pruebas y uno de producción. No es lo mismo que el desarrollador tenga acceso al ambiente de pruebas y pueda ir impactando correcciones individualmente a tener planificados una cierta cantidad de despliegues por ambiente. La motivación de las pruebas cambiará (¿focalizo la prueba en la corrección? ¿Será necesario contemplar una regresión con cada corrección? ¿Cuántos ciclos de prueba puedo planificar?), los tipos de prueba que aplicaré en cada ciclo pueden variar, y todo esto impacta en las dependencias de las tareas, en su cronología y en la estimación del esfuerzo.

  •  (6) Cuando el cliente participa de las pruebas, incluirlo en el plan de pruebas

¿El cliente participará de las pruebas? ¿Conviene involucrarlo de forma temprana? ¿Quiénes del lado del cliente harán pruebas? ¿En qué ambiente/s? ¿Debo contemplar horas de los recursos del proyecto para acompañar las pruebas del cliente? El conocimiento de los stakeholders, de qué tanta confianza nos tiene, de cuán firme o cambiante es en sus definiciones, de cuántas serán las personas que participen de la aceptación del producto, de si podrán hacer las pruebas por si mismos o requerirán guía/soporte del equipo del proyecto, de cómo se manejarán los potenciales bugs que puedan identificar, nos determinará aspectos que afectan la planificación de las pruebas. Las estrategias que se aplicarán deben indicarse en el plan de pruebas. Esto permite que la estimación resultante se asemeje a la realidad lo más posible respecto del esfuerzo que requerirá el proceso de pruebas.

  •  (7) Hablar un lenguaje común

¿Qué entendemos por objeto ítem de prueba? ¿Qué entendemos por caso de prueba? ¿Qué entendemos por ciclo de prueba? ¿Qué es una prueba de estrés, o de carga? No siempre todos los lectores del plan de pruebas le darán el significado que quiere transmitir quien escribe el plan de pruebas a las palabras y términos que usa el equipo de pruebas. Disponer de un glosario que acompañe el plan de pruebas es una buena práctica para que todas las personas que participan del proyecto entiendan lo mismo al momento de leer el plan de pruebas.

  •  (8) Comunicarlo

El plan de pruebas tiene como audiencia principal al equipo de pruebas porque es quien se compromete a llevarlo a cabo pero es importante comunicarlo al resto del equipo del proyecto. Debe ser revisado con el líder de proyecto quien tiene la visión del proyecto y de cómo lo administrará. Debe ser comunicado al equipo de desarrolladores, pues debemos estar todos de acuerdo en los objetos ítems de las pruebas (que deberían coincidir o serán un subconjunto de los que serán construidos). En algunos casos, a consideración del líder de proyecto, puede compartirse también con los stakeholders usuarios del proyecto, con quienes se podrán validar los criterios de aceptación y compartir la planificación de los ciclos de prueba de los usuarios.

  • (9) Mantenerlo actualizado o, dicho de otra manera: hacerlo para usarlo

Como todos los artefactos de la ingeniería de software, hacerlo para que quede perdido en una carpeta, desactualizado, sin haberse aplicado en el proyecto ninguna de las estrategias definidas es tirar el esfuerzo de haberlo hecho a la basura. El plan de pruebas se generará al inicio del proyecto, cuando aún no hay nada construido ni testeable. Muchas cosas pueden pasar hasta el momento en que efectivamente se ejecuta un ciclo de pruebas (¡ya conocemos el dinamismo de los proyectos!), estrategias del proyecto que determinaron aspectos del plan de pruebas pudieron verse afectados. Es por ello que el plan de pruebas debe ir siendo modificado según sucedan los acontecimientos. Mantenerlo actualizado sirve para poder identificar nuevos riesgos relacionados a lo comprometido originalmente, para poder definir nuevas estrategias o desestimar las que ya no apliquen. Para poder ir ajustando la estimación original del esfuerzo que será necesario para llevar a cabo las pruebas del proyecto de forma tal que se asemeje a la realidad lo mejor posible.

¡Gracias por tu contribución Cecilia Briozzo!

















jueves, 10 de julio de 2014

DYNAMICS CRM 2011 – DATOS ÚTILES

Microsoft Dynamics CRM es una herramienta software para Gestión de las Relaciones con Clientes (en inglés Customer Relationship Management) desarrollado por Microsoft.

Forma parte de la familia de software empresarial Microsoft Dynamics.

Desarrollar customizaciones de este sistema puede tornarse algo tedioso si no se conoce en detalle el SDK del mismo.

En este post se pretende dar una guía para dar los primeros pasos en la customizacion de este producto.

Como crear un proyecto de Dynamics CRM 2011 en Visual Studio

Existe un template de proyecto para Visual Studio (2010 en adelante) que nos provee de un entorno que nos facilita generar y organizar nuestro código.

Se listan a continuación una serie de pasos para la implementación del mismo:

1. Bajar e Instalar el SDK desde:

http://www.microsoft.com/en-us/download/details.aspx?id=24004

2. Instalar el Developer Toolkit desde:

SDK\Tools\DeveloperToolkit

3. Abrir Visual Studio. Hacer click File à New à Project

4. Seleccionar Dynamics CRM como tipo de proyecto

clip_image003

5. Elegir el nombre del proyecto y hacer click en el botón “OK”

6. Ingresar datos relevantes en la ventana de conexión al Server de Dynamics CRM:

clip_image005

NOTA: Después de completar las credenciales y apretar el botón Log On, se habilitaran las organizaciones a las cual su usuario tiene acceso.

Luego de seleccionar la organización, se habilitaran las soluciones contenidas en su interior. La solución elegida será la contenedora de nuestros archivos al momento de hacer deploy desde el proyecto de Visual Studio

7. Firmar el Proyecto de Plugins:

a. Click derecho sobre el proyecto “Plugins”

b. Click sobre la opción “Propiedades”. Se abrirá la siguiente ventana:

clip_image007

c. Click sobre el tab “Signing”

d. Tildar el check box “Sign the assembly”

e. Seleccionar la opcion “New”

clip_image009

f. Completar los campos asignándole un nombre a la firma, así como también un password

Cómo Manejar los Web Resources desde Visual Studio

El template de desarrollo de Dynamics CRM 2011 para Visual Studio, nos da la posibilidad de agregar los Web Resources existentes en nuestro entorno de Dynamics CRM a nuestro proyecto.

Agregar un Web Resource al Proyecto de Visual Studio

Detallamos aquí los pasos para hacerlo:

1. Abrir el menú “CRM Explorer”

2. Hacer click sobre la Organización

3. Desplegar el menú de Web Resources

clip_image011

4. Click derecho sobre el Web Resource que se quiere agregar al proyecto de VS.

5. Click sobre “Add to packaging project”

clip_image013

Una vez hecho esto, tendremos acceso desde el “Project Explorer” a todos los WR que hayamos agregado al proyecto.

clip_image015

NOTA: Cada vez que hagamos Deploy del proyecto, por defecto también se hará deploy de todos los Web Resources.

Se recomienda cambiar la propiedad “Build Action” del Web Resource a “none” para que esto no suceda.

clip_image017

Implementar Modificaciones en Dynamics CRM

Existen varias formas de implementar los cambios realizados en el código de los Web Resources.

Describiremos aquí dos procedimientos que son válidos y uno que no lo es.

INVALIDO – Copiar el código dentro del “Text Editor” de la UI de Dynamics

En antiguas versiones de Dynamics CRM no existían los Web Resources.

La implementación de código Javascript se hacía embebiendo el código en una sección que la UI de CRM nos otorgaba para tal fin.

Al parecer, muchos desarrolladores siguieron con la misma costumbre de “Copiar y Pegar” el código en Dynamics CRM 2011.

Esto no se debe hacer, ya que a partir del Rollup update 8, este “Editor de Texto” nos trunca el código en 2000 caracteres.

clip_image019

RECOMENDADO – Implementar las Modificaciones Desde el Archivo con el Código Fuente

Este procedimiento es fácil y nos da la seguridad de que estamos implementado exactamente las modificaciones que queremos implementar.

Tiene como ventajas que es claro, rápido y transparente.

Tiene como desventaja que es un poco tedioso para implementaciones masivas (muchos Web Resources al mismo tiempo).

Detallamos cómo hacerlo:

1. Abrir el CRM Explorer.

2. Hacer doble Click sobre el Web Resource a Actualizar.

(Esto abrirá la ventana del Web Resource dentro de nuestro entorno de VS)

clip_image021

3. Abrir desde el Project Explorer el archivo con el código fuente.

4. Click derecho sobre la solapa del archivo.

5. Click sobre la opción “Copy full path”

clip_image023

6. Click sobre el botón “Browse…” en la ventana del Web Resource (CRM UI)

7. Pegar el path copiado.

8. Click sobre el botón “Save”

9. Click sobre el botón “Publish”

VÁLIDO – Deploy del Proyecto

Al hacer Deploy del proyecto (Ver Sección 5), todos los web resources cuya propiedad “Build Action” sea “CRM WebResource” serán implementados en nuestro entorno de Dynamics CRM.

Para que los cambios cobren efecto, se deberá hacer un “Publish” desde la UI de Dynamics CRM.

Este procedimiento tiene como ventaja la posibilidad de hacer Deploy de muchos web resources al mismo tiempo.

Como desventaja lidiamos con que, al hacer deploy,,si no especificamos lo contario, estamos implementando tanto web resources, como plugins, como implementaciones Silverlight y todo lo que tengamos en nuestro proyecto.

En general, tomar todos los recaudos para que únicamente se implemente el código que queremos se torna tedioso.

Además, suele tardar más tiempo que el procedimiento anteriormente descripto.

Cómo Crear Plugins en Dynamics CRM 2011 usando Visual Studio

1. Abrir el menú “CRM Explorer”

2. Hacer click sobre la Organización

3. Desplegar el menú de entidades

clip_image025

4. Click derecho sobre la entidad para la cual se quiere generar un plugin

5. Click sobre la opción “Create Plugin”

clip_image027

Se abrirá una ventana en la cual se deberá configurar el plugin a crear.

Dicha ventana la describiremos a continuación:

clip_image029

a. Message: Es el “Mensaje” o “Step” en el cual se va a atachar el plugin. Es decir, que evento va a disparar la ejecución del plugin. Los de uso más extendido son:

i. Update: Los plugins registrados en este Step se dispararan cuando un registro haya sido actualizado

ii. Create: Los plugins registrados en este Step se dispararan cuando un registro haya sido creado.

iii. Assign: Los plugins registrados en este Step se dispararan cuando un registro haya sido asignado a un usuario distinto al que lo está actualmente.

iv. Delete: Los plugins registrados en este Step se dispararan cuando un registro haya sido borrado.

v. Retrieve: Los plugins registrados en este Step se dispararan cuando Dynamics hace la solicitud de un registro a la base de datos.

b. Run in Context: Al hacer click en este menú, se despliega una lista de todos los usuarios contenidos en la organización de crm y además una opcion, que viene seleccionada por defecto, llamada “Calling User”.

Este campo determina si el plugin deberá ejecutarse sin importar que usuario dispare el evento (Calling User) o solo si es disparado por un usuario en particular.

c. Pipeline Stage: En Dynamics, además de elegir en que evento vamos a atachar un plugin, debemos explicitar también un “Pipeline Stage”.

Cada evento, en CRM, está compuesto en realidad de dos eventos:

i. Pre-Operation: Se dispara antes de que los cambios en el registro hayan impactado en la base de datos.

ii. Post-Operation: Se dispara después de que los cambios hayan impactado en la base de datos.

d. Pre Image Alias: Si completamos este campo, entonces, se generara automáticamente en el plugin, un objeto del tipo Entidad conteniendo el valor de los atributos que hayamos seleccionado como parámetros ANTES de haberse producidos los cambios que dispararon el plugin..

e. Post Image Alias: Si completamos este campo, entonces, se generara automáticamente en el plugin, un objeto del tipo Entidad conteniendo el valor de los atributos que hayamos seleccionado como parámetros DESPUES de haberse producidos los cambios que dispararon el plugin.

f. Class: Nombre de la clase.

g. Deployment: Desde este atributo se determina en que cliente de Dynamics CRM – ya sea Server Only, Outlook only o ambos - se hará deploy del plugin en cuestión.

6. Hacer click en el botón “OK”.

Se generara una clase dentro del proyecto “Plugins”.

Esta clase hereda de Plugin, que a su vez implementa la interfaz IPlugin, definida en el SDK de Dynamics.

Consideraciones y consejos para el desarrollo de Plugins en Dynamics CRM

Como instanciar el registro siendo modificado

En Dynamics, podemos instanciar un objeto que contenga la modelización del registro cuya modificación disparo el plugin.

Para instanciar un objeto del tipo Entity / EntityReference se deberán utilizar las siguiente líneas de código:

1.

clip_image030

Para los siguientes Steps: Create, Update, Delete.

2. Para el step Assign:

a.

clip_image031

Registro en cuestion:

b. Registro que fue asignado como responsable del registro en cuestión:

clip_image032

Como hacer Deploy de los plugins en Dynamics CRM desde Visual Studio

clip_image034

1. Cerciorarse de que el archivo “RegisterFile.crmregister” no se encuentra bloqueado ni tomado por otro usuario.

2. En el Solution Explorer, hacer click derecho sobre el proyecto “CrmPackage”

3. Hacer click en la opción “Deploy”

Una vez hecho esto, nos aparecerá un icono, en la barra inferior del VS, indicando el estado del proceso. Una vez finalizado, se leerá la leyenda “Deploy Succeeded”.

Exportar / Importar Plugins desde CRM

Una vez instalados los plugins desde VS, se puede acceder a ellos desde CRM.

Visual Studio implementa los plugins en CRM creando:

clip_image001 Un archivo <<NombreDelProyexto>>.dll por cada proyecto del que se hace deploy.

clip_image001[1] Un archivo <<NombreDeLaClaseDelPlugin>> por cada plugin que hayamos registrado en el RegisterFIle.crmregister

Para importar / exportar los plugins se los debe agregar a una solución de Dynamics CRM y proceder mediante el circuito nativo para importar / exportar soluciones.

Dynamics CRM 2011 y Javascript

Al desarrollar customizaciones para Dynamics CRM 2011 nos encontraremos con que muchas de ellas se deben desarrollar utilizando javascript.

Para ello contamos con distintas librerías que nos ayudan a realizar dichas customizaciones.

Describiremos a continuación una de las más útiles.

XRMServiceToolkit.js

Link de descarga: http://xrmservicetoolkit.codeplex.com/releases

Esta librería nos da una fácil implementación de cosas como:

clip_image001[2] Métodos comunes: Cambios en el formulario de CRM (deshabilitar y / ocultar campos, obtener valores de campos, etc).

clip_image001[3] Métodos Rest Endpoint: Crear, consultar, actualizar campos, etc.

clip_image001[4] Métodos Soap: Crear, consultar, actualizar campos, etc.

clip_image001[5] Métodos complementarios: Configurar OptionSets dependientes uno de otros, Agregar Tooltip a campos, Agregar vistas filtradas a Lookups, etc.


Crear un Registro
clip_image035

Hacer Retrieve de un Registro
clip_image036
Actualizar un Registro
clip_image037
Eliminar un Registro
clip_image038

Asociar dos Registros
clip_image039
Desasociar dos Registros
clip_image040
RetrieveMultiple
clip_image041

Ejecutar una consulta FETCHXML
clip_image042

Ejecutar una consulta por atributo
clip_image043

Xrm.Page Object Model

Microsoft Dynamics CRM introduce un nuevo modelo de objeto para interactuar con su entorno: “Xrm.Page”.

Este modelo de objeto permite, entre estas cosas:

clip_image001[6] Mostrar / Ocultar elementos de la UI.

clip_image001[7] Soportar controles múltiples por atributo.

clip_image001[8] Soportar formularios múltiples por entidad.

clip_image001[9] Manipular ítems de navegación entre formularios.

Es importante destacar que este objeto únicamente incluye en sus colecciones a los atributos que fueron materializados como un campo en el formulario. Por lo tanto, si un atributo existe, pero no está incluido como un campo en el formulario, el Xrm.Page Object Model no lo incluirá en sus colecciones.

Jerarquía

Como se muestra en el siguiente diagrama, Xrm.Page provee un namespace para tres objetos descriptos en la siguiente tabla:

Objeto

Descripción

context

Provee métodos para hacer un retrieve de información específica de una organización, un usuario, o parámetros que fueron pasados al formulario a través de una QueryString.

data

Provee acceso a la información de la entidad.

ui

Contiene métodos para hacer un retrieve de información de la UI. Además, brinda acceso a distintos sub componentes del formulario

clip_image045

Métodos Útiles

Acción

Sintaxis

Notas

Obtener el valor de un campo.

Xrm.Page.getAttribute("<<NombreDelCampo>>").getValue()

Obtener el texto de la opción seleccionada en un OptionSet

Xrm.Page.getAttribute("<<NombreDelCampo>>").getSelectedOption().text

Setear el Valor de un campo

Xrm.Page.getAttribute("<<NombreDelCampo>>").setValue(<<Nuevo Valor>>)

Establecer el modo de submit de un campo

Xrm.Page.getAttribute(("<<NombreDelCampo>>").setSubmitMode(("<<SubmitLevet>>")

Submit Levels:

•always

•never

•dirty

Establecer el nivel de requerimiento del campo

Xrm.Page.getAttribute(("<<NombreDelCampo>>"). setRequiredLevel("<<NivelDeRequerimiento>>")

Nivel de Requerimiento:

•none

•required

•recommended

Deshabilitar / Habilitar un control

Xrm.Page.getControl("<<NombreDelCampo>>").setDisabled(true);

•true à Deshabilitado

•false àHabilitado

Obtener Id del usuario logueado

Xrm.Page.context.getUserId()

Obtener Url del Server

Xrm.Page.context.getServerUrl()

Obtener Id del registro en el cual se está ejecutando el script

Xrm.Page.data.entity.getId()

Cambiar de formulario

Xrm.Page.ui.formSelector.items.get("<<NumeroDeFormulario>>").navigate()

Identificar si el formulario es de creación, actualización, etc.

Xrm.Page.ui.getFormType()

•Si devuelve 1 à El contexto del formulario es de creación.

Si Devuelve 2 àEl contexto del formulario es de actualización.

Interrumpir el evento “Save” del formulario

(Habiendo pasado el contexto del evento como parámetro “event”)

event.getEventArgs().preventDefault();

ClientGlobalContext.js.aspx

Esta librería es nativa de Dynamics CRM 2011 y nos brinda un acceso a la información del contexto en el cual se esté ejecutando un web resource.

La función ClientGlobalContext devuelve el mismo objeto encontrado en Xrm.Page.context.

Cuando se esté programando un web resource javascript para un formulario, se deberá usar el objeto Xrm.Page.context.

Cuando se necesite información del contexto fuera del formulario (por ejemplo, en un web resource .html embebido en el formulario), se deberá incluir una referencia a ClientGlobalContext.js.aspx.

….Enjoy coding!

Referencias

1. http://msdn.microsoft.com/en-us/library/hh372957.aspx, Developer Toolkit for Microsoft Dynamics CRM.

2. http://xrmservicetoolkit.codeplex.com , XrmServiceToolkit - A Microsoft Dynamics CRM 2011 & CRM 2013 JavaScript Library.

3. http://msdn.microsoft.com/en-us/library/gg328541.aspx , GetGlobalContext Function.

4. http://msdn.microsoft.com/en-us/library/gg328474.aspx, Xrm.Page Objetc Model.

5. http://blogs.msdn.com/b/arpita/archive/2012/02/19/microsoft-dynamics-crm-2011-force-submit-on-a-disabled-field-or-read-only-field.aspx

6. http://es.wikipedia.org/wiki/Microsoft_Dynamics_CRM, ¿Qué es Microsoft Dynamics CRM?

¡Gracias por tu contribución Santiago Díaz!