El próximo día 17 de Abril a las 19:00 tengo el placer de dar una charla con el título ¿Porque debería automatizar mis pruebas? dentro del marco de actividades del grupo WebDev Bilbao en el Centro de Innovación Social de Bilbao.
En la misma hablaremos, entre otras cosas, sobre:
- Cuales son los aspectos más importantes a la hora de automatizar nuestras pruebas.
- Que podemos aspirar a conseguir con dicha automatización.
- Candidatos a la automatización.
- Porque automatizar las pruebas es más que una técnica.
- Terminología del mundo de las pruebas.
- Economía de la automatización de pruebas.
- ROI.
- Características del buen test.
- Problemas comunes.
- Como organizar nuestros tests.
- Métodos de diseño de tests.
- Tipos de tests (que no solo existen test unitarios!!)
- Estrategias de verificación.
Vamos, de todo un poco sobre un tema tan interesante como es el de la automatización de nuestras pruebas.
Os espero por ahí para hacer el evento lo más interesante posible.
Es tiempo de cambios para mí. Dejo de trabajar en Panda Security para comenzar una nueva etapa en Plain Concepts.
Haciendo balance de mi paso por Panda Security, el resultado es francamente positivo. He aprendido mucho, trabajando en equipos formados por gente muy diferente (alemanes, cubanos, americanos…) lo cual me ha permitido evolucionar como profesional y como persona. Tópico, pero verdad…
Entonces, por que cambiar?
Pues porque es mucho lo que espero de mi nueva empresa:
- Gestión ágil (de verdad), con todo lo que eso implica.
- Proyectos interesantes, avanzados tecnológicamente y con requerimientos exigentes.
- Compañeros motivados, capaces de compartir sus conocimientos y estar abiertos siempre a la mejora. Conozco hace tiempo a mucho de ellos de la comunidad, eventos y otro saraos. Son el tipo de gente con el que da gusto trabajar.
- Conocer un montón de gente interesante de la que aprender, tanto dentro como fuera de la empresa. Trabajando duro para ser el peor, como comentaba Dawn Cannan en su articulo: Be the Worst en Agile Record)
Un sitio definitivamente donde poder trabajar con alta motivación, que me ayude a evolucionar aportando mi esfuerzo y plantee retos que sean beneficiosos para ambas partes.
Estoy seguro que esto y mucho más va a ser lo que voy a encontrar allí.
Estamos en contacto.
El otro día hablábamos de las limitaciones de comunicación entre aplicaciones Metro y Desktop hospedadas en la misma máquina establecidas en Windows 8. De hecho, hablábamos de la “NO” comunicación entre Metro y Desktop. Los pistoleros más rápidos dirán que donde dije Digo ahora digo Diego, pero esperar un poco antes de apedrearme en la plaza pública…
Comentábamos que por diseño, invocar desde una aplicación Metro a un servicio WCF expuesto en la misma máquina, no está permitido. Esto puede ser una restricción demasiado estricta (y totalmente injustificadas) si estamos desarrollando en la misma máquina el servicio y la parte Metro que la consume.
Para este tipo de casos (y no para saltarnos el control, que no tenéis una idea buena...) contamos con una herramienta de línea de comandos llamada CheckNetIsolation. Podemos leer un poco más al respecto aquí http://msdn.microsoft.com/en-us/library/windows/apps/hh452759.aspx
Acorde a dicha restricción, al acceder a dicho servicio, la aplicación Metro (sin ningún tratamiento previo) recibiremos una excepción del tipo EndPointNotFopundException con un mensaje tal que así:
{"There was no endpoint listening at ... that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details."}
Ok, a menos de que creas que la gente de Microsoft va de farol, es lo esperado, no?
Ahora viene lo interesante. Para permitir este tipo de comunicación (recuerda que la limitación solo se aplica a la misma máquina) debes seguir estos pasos:
Lo primero que debemos hacer es buscar en el registro la clave de la aplicación Metro con la que deseamos hacer la excepción. Para ello, abrimos el Regedit y buscamos la clave de la aplicación que cuelga de:
HKEY_CURRENT_USER\Software\Classes\Local Settings\Software\Microsoft\Windows\CurrentVersion\AppContainer
Fíjate en el valor de la propiedad displayname para poder identificarla.
Una vez que sepamos la rama concreta, puedes seleccionarla con el botón derecho y copykeyname y selecciona el nombre de la carpeta del mapping (desde S-1-15... hasta el final). Este <keyname> nos permitirá establecer la excepción más adelante.
A continuación, abre el “Developer Command Promp” y escribe “CheckNetIsolation” para acceder a la utilidad. Pégate una leidita el enlace anterior para evaluar un poco mas en detalle las capacidades de la herramienta.
En nuestro caso debemos escribir:
- Para ver el listado de las aplicaciones ya excluidas del bloqueo de loopback:
CheckNetIsolation.Exe LoopbackExempt –s
- Para incluir nuestra aplicación como una excepción:
CheckNetIsolation.exe LoopbackExempt -a -p=<keyname>
- Para comprobar que ya ha sido correctamente incluida, pues vuelve a ejecutar el comando anterior (nunca te lo hubieses imaginado, verdad?)
CheckNetIsolation.Exe LoopbackExempt -s
Una vez hecho esto, ya podremos consumir servicios de la misma máquina sin recibir la excepción comentada al principio del post, comprobado!!
Windows 8 va cogiendo forma, y lo que vamos viendo nos confirma que la gente de Redmond está haciendo una apuesta muy fuerte por evolucionar su sistema hacia diferentes dispositivos. Un único sistema operativo para ordenadores y tabletas (dejemos los teléfonos de momento…) implica un profundo replanteamiento del mismo, desde sus cimientos.
Por un lado tenemos un gran hito para Windows 8 es la necesidad de correr sobre procesadores ARM. Por otro lado, Microsoft tradicionalmente se aplica en maximizar la compatibilidad hacia atrás. Este es un compromiso que tradicionalmente le ha diferenciado de la competencia digamos más “intrépida” en sus evoluciones/revoluciones.
El resultado de aplicar este par de fuerzas, en principio opuestas (compatibilidad hacia atrás VS evolución hacia la ligereza) implica casi tener dos sistemas operativos en uno. Es muy interesante la lectura de este post Windows 8 – A Tale of Two Platforms al respecto.
Siempre que se produce un cambio profundo como este, se generan por un lado un buen montón de riesgos a mitigar así como otro montón de oportunidades a aprovechar. Cuando comenzamos a evaluar la posibilidad de que nuestras aplicaciones corran sobre Windows 8 siempre comenzamos a pensar en los componentes que la conforman y en como ir migrándolos hacia la nueva plataforma.
Quien más quien menos ha oído o va a oír al respecto:
“Este servicio lo dejo igual y desde la interfaz metro lo invoco y...”
Pero en esta aproximación hay un demonio escondido: crea un dependencia de la parte de aplicaciones “Metro” hacia la parte “Desktop” y ese no es el camino que Microsoft fomenta. Tengamos en cuenta que si todos los desarrolladores aplican ese proceso, la parte “Metro” de Windows 8 nunca podrá correr sin la parte “Desktop”. Ese es el precio a pagar por dicha dependencia.
Podemos ver esta división en el siguiente gráfico:
Comprobamos que no existe un canal de comunicación oficial por encima del Kernel de Windows (que obviamente, comparten) para realizar comunicaciones entre aplicaciones “Metro” y “Desktop”.
La pregunta (muy común y cada vez más) es clara:
¿Como puedo comunicar entre aplicaciones Metro y Desktop?
La respuesta no es tan clara, pero desde luego no es algo que en principio Microsoft fomente.
El modelo de procesamiento en la nube y clientes ligeros es el candidato por todas las grandes a la hora de llegar a diferentes dispositivos y es también es el que Microsoft promociona. Este escenario ha demostrado su éxito en la competencia y algo sabe esta empresa de aprender de los demás.
Una posible solución (por supuesto depende de la naturaleza de cada aplicación) es llevar toda la lógica de tu aplicación a tu proveedor de Cloud (Azure, Amazon, GAE…) y dejar un cliente bien ligero en “Metro” que consuma de manera optimizada dichos servicios. (Debemos tener en cuenta que en Metro solo se ha migrado la parte de cliente de WCF!!).
Obviamente este modelo también tiene su problemática a resolver, como por ejemplo como comportarse en caso de no tener comunicación.
Con el fin de confirmar las limitaciones de comunicación entre aplicaciones “Metro” y “Desktop” podemos leer:
- Ale Contenti comentaba que la comunicación entre aplicaciones de ambos mundos es a nivel de archivo. (aunque también dice que es muy pronto para confirmarlo)
http://channel9.msdn.com/Events/BUILD/BUILD2011/TOOL-789C
- Otra idea podría ser montar un Servicio Web en la parte Desktop:
Respecto a eso, podemos leer a Jeff Sanders en los foros de soporte de Microsoft:
“You cannot access a WebService on the same machine. The WebService would need to be external to the machine ... In Metro you cannot use IPC except with Metro Style applications that are in the same package.”
Otro día hablamos de CheckNetIsolation.exe, prometido!
- Pero estas restricciones de comunicación no solo existen a alto nivel. Podemos leer a Pavel Minaev:
”… Named pipes aren't there, for example, nor are memory mapped files. There are sockets (including server sockets), but when connecting to localhost, you can only connect to the same app. You could use normal files in one of the shared "known folders" (Documents, Pictures etc), but that is a fairly crude hack that necessitates polling and is visible to the user.”
A buen entendedor pocas palabras bastan. Podemos ver claro que este canal de comunicación no es el deseado. Y esto es comprensible, puesto que si pensamos un poco en los diferentes escenarios sobre los que deseamos corra Windows 8 podemos observar que:
- PCs Legacy corriendo Windows 8 donde se ejecutarán aplicaciones Legacy pero no van a aprovechar las bondades de las aplicaciones basadas en interfaces táctil (Metro/WinRT)
- Tabletas x86 donde podrán correr aplicaciones Legacy que por otro lado, si sacaran el máximo a las aplicaciones metro. Eso si, tendremos que tener en cuenta temas como peso, vida de la batería, coste...
- Tabletas basadas en ARM donde las aplicaciones Legacy (salvo que Microsoft se saque algo de la chistera...) no van a correr, pero sacarán el máximo de Metro.
Resumiendo, podemos decir que Windows 8 tiene dos caras, es muy importante comprender esto para poder afrontar las migraciones y nuevos desarrollos con la perspectiva adecuada al nuevo panorama que se nos presenta.
Reconozcámoslo, automatizar cualquier proceso es gratifícateme pero no siempre es fácil. Todos alguna vez hemos aparcado muy buenos propósitos (como los año nuevo…) debido a los impedimentos encontrados por el camino.
He sufrido este fenómeno recientemente en una empresa que todos conocemos (y no puedo nombrar ;)) hace bien poquito con un intento de aplicar TDD en los equipo de desarrollo debido a los plazos de entrega tan ajustados que se manejaban.
Sintiéndolo mucho, debemos decir que esto es lo normal.
Afortunadamente igual de normal tener el deseo de mejorar y eso nos impulsa hacia caminos que sabemos van a ser ventajosos. Uno de ellos es automatizar las pruebas en nuestros proyectos. En torno a un 40% del tiempo destinado a un proyecto se dedica a probar, así que invertir en este campo parece una apuesta segura.
Centrándome en el propósito del post (que me voy por las ramas) hace poco he estado trabajando con un equipo que tenía algunas dudas frente a como automatizar las pruebas sobre algunas clases de una determinada funcionalidad.
Poco más o menos la queja era:
Tenemos una clase que no podemos desacoplar (como nos has dado la paliza 100 veces) puesto que .NET me obliga a que herede de otra puesto que lee del fichero de configuración...
Por no entrar a demasiado detalle digamos que tenían unas clases que ellos creían POCO, pero que realmente no lo eran, puesto que tenían unos bonitos atributos que se habían pasado por alto.
La solución del problema fue crear un mock la clase directamente (los frameworks de Mock “modernos” nos permiten hacer esto) y mockear de ciertas propiedades que se estaban consumiendo desde el código para conseguir el nivel de aislamiento necesario y poder realizar las prueba unitaria. Por supuesto, desde la prueba unitaria tuvimos que añadir los mismos atributos que tenía el código real y conseguimos que el test funcionara correctamente.
Lo más interesante de todo esto son las conclusiones que podemos extraer de la experiencia:
Cuando en DDD hablamos de que las clases deben ser POCO es por algo. Todo lo demás es infraestructura. La tecnología es infraestructura. En este ejemplo, esos atributos tan inofensivos, son tecnología y hacen que esas clases aparentemente POCO no lo sean. (se mapean de un fichero de configuración!!)
Por eso digo en el título que estos POCO son lobos con piel de cordero.
La siguiente pregunta es ¿Debemos probar el código de infraestructura?
Pues la respuesta es SÍ. Es parte de nuestra aplicación y debemos probarlo, pero probablemente tengamos una política de testeo diferente. Debemos en la medida de lo posible, hacer que dichos “adaptadores” sean lo más sencillos posibles facilitando su testo.
Podemos decidir alcanzar una cobertura menor en pruebas unitarias y realizar un mayor esfuerzo en pruebas de integración.
Como siempre, la clave del éxito radica ajustar la relación del esfuerzo que nos supone desarrollar (y mantener) una batería de pruebas optima para en contexto (Core Business / Infraestructura…) en el que nos encontramos, con el retorno de valor que de la mismas obtenemos.
Por cierto, feliz 2012 ;)
Últimamente por motivos relacionados con mi trabajo me he tenido que ir introduciendo cada vez más y más en el mundo de la seguridad informática. Es un campo muy extenso e interesante pero también un tanto oscuro en algunos puntos. (sobre todo si no das con las fuentes de información adecuadas)
En este ecosistema de seguridad, como ya conocemos todos en mayor o menor medida, los certificados de seguridad juegan un papel de lo más importante. ¿Quien no ha oído hablar de los certificados X509?
Windows incluye una herramienta para gestionar los certificados que tenemos instalados en la máquina/máquinas. Más concretamente es un complemento de la Microsoft Management Console (a.k.a. navaja suiza) llamado “Certificates”. Esta herramienta es de lo más conocida y podéis encontrar mucha documentación sobre ella en el MSDN, por ejemplo aquí.
Curioseando con la instalación de los certificados me surgió la pregunta sobre donde Windows almacena la clave privada de los mismos. Leyendo una poco al respecto, encontré una herramienta que nos aporta dicha información llamada Find Private Key Tool.
Dicha herramienta nos permite a través de la línea de comandos, preguntar sobre un determinado certificado ( filtrando por diferentes características como su subject, thumbprint…). En caso de existir un certificado que se adapte a los parámetros solicitados, nos retornara el nombre del fichero que le da soporte. Esta información nos puede ser necesaria en caso de tener que ajustar los permisos de las acciones que sobre el mismo se deben permitir. El caso más típico es acceder a la clave privada de un certificado (por código) con un usuario con permisos restringidos (por ejemplo el application pool identity de una aplicación ASP.NET)
Según la especificación de la herramienta:
1: Usage: FindPrivateKey <storeName> <storeLocation> [{ {-n <subjectName>} | {-t <thumbprint>} } [-f | -d | -a]]
2: <subjectName> subject name of the certificate
3: <thumbprint> thumbprint of the certificate (use certmgr.exe to get it)
4: -f output file name only
5: -d output directory only
6: -a output absolute file name
Ejemplos de comandos:
Buscar en StoreName “My” y Store Location “CurrentUser” un certificado con el Subject CN=TESTCERT (CN es el Common Name, que forma parte del Subject)
1: FindPrivateKey My CurrentUser -n "CN=TESTCERT"
Buscar en StoreName “My” y Store Location “LocalMachine” un certificado con el Thumbprint pasado por parámetro
1: FindPrivateKey My LocalMachine -t "40 ee 7b 2f 10 59 38 99 4f 65 9f 8f 92 38 85 a3" –c
En caso de que el certificado solicitado exista, la herramienta nos devolverá algo como:
1: Private key directory:
2: C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys
3: Private key file name:
4: <GUID>
Siendo el GUID el nombre del fichero asociado que almacena la clave privada. Una vez localizado podemos modificar sus permisos si para alguno de nuestros procesos esto es necesario.
Silverlight nace para cubrir las necesidades de aplicaciones RIA, y como sabemos, las aplicaciones de Internet son exigentes en muchos aspectos. Es debido a dicha concepción, que posee ciertas características muy interesantes para escenarios para los que originalmente no fue creado.
Por ejemplo, la huella en memoria de Silverlight es sensiblemente menor que incuso para el .NET Framework Client Profile. Además el tamaño del instalador es también varias veces menos que dicho (de 28MB a 6MB ). Estos detalles que nos pueden parecer banales, no lo son tanto, si multiplicamos dichas diferencias por muchos millones de descargas o requerimientos de Hardware…
Teniendo en cuenta estas ventajas y que las partes más comunes de WPF se encuentra también presente en Silverlight, este se presenta como un candidato válido para desarrollo de aplicaciones de escritorio. (Ahora que está tan de moda HTML5/JS…)
Este modo de trabajo se conoce como “out of browser” (OOB). Tengamos en cuenta que la misma aplicación puede ejecutarse dentro y fuera del navegador, en principio, en base a que el usuario decida instalarla.
Si deseamos desarrollar aplicaciones de escritorio, podríamos distribuir nuestro .xap como parte del instalador de la aplicación completa, evitando dar la posibilidad de ejecutarla en el navegador (El host va a ser el sllauncher.exe)
Las mayores restricciones en este aspecto están relacionadas con la interacción con el Sistema Operativo y acceso a recursos de la máquina local. Si vuestro conjunto de requisitos de interacción en el puesto cliente no son muy elevadas, es posible que Silverlight pueda ser vuestra tecnología de cliente.
En esta forma de trabajo, debemos evaluar la conveniencia de algunos de los planteamientos del equipo de Microsoft y adaptarlos a nuestras necesidades. La gestión predeterminada de las excepciones no gestionadas que nos propone Visual Studio no está pensada si deseamos crear una aplicación de escritorio.
Si vemos el código que nos propone el Visual Studio al crear el proyecto de Silverlight observamos:
1: private void Application_UnhandledException(object sender, ApplicationUnhandledExceptionEventArgs e)
2: {
3: // If the app is running outside of the debugger then report the exception using
4: // the browser's exception mechanism. On IE this will display it a yellow alert
5: // icon in the status bar and Firefox will display a script error.
6: if (!System.Diagnostics.Debugger.IsAttached)
7: {
8:
9: // NOTE: This will allow the application to continue running after an exception has been thrown
10: // but not handled.
11: // For production applications this error handling should be replaced with something that will
12: // report the error to the website and stop the application.
13: e.Handled = true;
14: Deployment.Current.Dispatcher.BeginInvoke(delegate { ReportErrorToDOM(e); });
15: }
16: }
17:
18: private void ReportErrorToDOM(ApplicationUnhandledExceptionEventArgs e)
19: {
20: try
21: {
22: string errorMsg = e.ExceptionObject.Message + e.ExceptionObject.StackTrace;
23: errorMsg = errorMsg.Replace('"', '\'').Replace("\r\n", @"\n");
24:
25: System.Windows.Browser.HtmlPage.Window.Eval("throw new Error(\"Unhandled Error in Silverlight Application " + errorMsg + "\");");
26: }
27: catch (Exception)
28: {
29: }
30: }
Como vemos se incluye una función para interactuar con el DOM. Esto no tiene sentido si nuestra aplicación va a correr siempre en modo OOB. Además comprueba si no tenemos el depurador adjunto para realizar esta notificación…
Vamos a comenzar a modificar este comportamiento para que se adapte a nuestras necesidades.
Lo primero vamos a hacer es cambiar el código del método Application_UnhandledException y eliminar la función ReportErrorToDOM.
El resultado quedaría algo así:
1: private void Application_UnhandledException(object sender, ApplicationUnhandledExceptionEventArgs e)
2: {
3: e.Handled = true;
4: new ExceptionDetailView {DataContext = new ExceptionDetailViewModel(e.ExceptionObject)}.Show();
5: }
Sencillo, verdad?
Antes de nada marcamos como tratado el parámetro recibido para notificar que ya ha sido tratada y que no escale más por la pila de excepciones. Además mostramos un mensaje de error por pantalla notificando al usuario que se ha producido un error.
Este sería un punto interesante para guardar en el log de la aplicación la información más detallada de la excepción, que seguro el departamento de soporte nos lo agradecerá.
Si deseáis incluir una buena gestión de log en Silverlight os recomiendo usar el Silverlight Integration Pack for Microsoft Enterprise Library 5.0.
Ahora la pregunta es que es ExceptionDetailView?
Pues no es más que una vista que creamos para mostrar el mensaje de error de manera agradable para el usuario. La particularidad de la misma, es que es una ChildWindow clase que se incluye en Silverlight desde la versión 3.
Esta clase nos permite colocar un control de usuario simulando una ventana modal. Es decir, deshabilita y oscurece el fondo. Este es el comportamiento que deseamos para mostrar nuestra excepción de modo que quede algo como esto:
En la implementación de la vista empleamos el patrón MVVM, sobre el cual existen toneladas de información. (y eso en raras ocasiones es bueno…)
Resumiendo podemos decir que disponemos de un ViewModel (ExceptionDetailViewModel.cs) y una vista que se encarga de pintar los datos que ese ViewModel expone por pantalla. (ExceptionDetailView.xaml)
La vista tiene asociada en su DataContext el ViewModel y vía Binding implementamos el conexión entre los datos y su representación gráfica.
Además de los datos es responsabilidad del ViewModel exportar la funcionalidad (vía comandos) que la vista puede invocar. En este caso, nuestro ViewModel expone un comando a la vista (ToggleShowingExceptionDetailCommand) que le permite mostrar u ocultar la información detallada de la excepción, para contentar a los más curiosos…
Pues ya solo queda probar, porque nos encanta probar, verdad??
Y en este caso debemos lanzar una excepción (al gusto, yo me he decantado por una IndexOutOfRangeException) y comprobamos que la aplicación muestra el mensaje de error de manera correcta en vez de quedarse en blanco.
Espero que os resulte interesante la idea y os incluyo el código fuente de la aplicación de ejemplo para que podáis probar su funcionamiento. Podéis consultar este y otros prototipos aquí (el nombre del archivo de esta solución es Andoni.Arroyo.UnhandledException )
Una de las cosas que más me gusta de .NET es lo rápido y consistente que evoluciona. Cuando cubre alguna funcionalidad, lo hace de manera elegante y bien terminada. Como desarrolladores es un gusto consumir las clases que exponen dicha funcionalidad y la experiencia suele ser de lo mas gratificante.
Nuestra responsabilidad como desarrolladores es conocer lo que nos brinda y aprovechar al máximo las ventajas que dichas evoluciones nos aportan. Esto nos permite centrar nuestros esfuerzos en las tareas que más valor aportan delegando en el framework las tareas más rutinarias y que aun siendo necesarias no dan valor al producto.
Un ejemplo de estas mejoras, incluida en el Framework 4 cubre un escenario más común de lo que parece, como es implementar un thread-local storage, conocido como TLS.
Imaginemos que deseamos realizar ciertas tareas en paralelo. Común, verdad? Además imaginemos que para el correcto procesamiento de esas instrucciones cada uno de los hilos necesita manejar sus datos de manera separada de los demás hilo de procesamiento que ejecuta un mismo código. Esto es, cada hilo en el que se están procesando las instrucciones, dispone de una copia propia y separada de los recursos que necesita para dicho procesamiento.
Esta característica es interesante si por ejemplo exponemos cierta funcionalidad a través de un Singleton (o un conjunto determinado de instancias), pero necesitamos permitir que dicho código pueda ser invocado desde diferentes hilos. También puede ser interesante si trabajamos con algún recurso no manejado que no soporte MTA (como la implementación del COM Interop de Silverlight, por ejemplo…) o si tenemos un código heredado que deseamos modificarlo para soportar ciertas características de procesamiento en paralelo, aplicando los mínimos cambios posibles.
Para cubrir esta funcionalidad desde el .NET Framework 1.1 existe el atributo [ThreadStatic] que brinda una forma elegante de implementarlo.
Veamos con un poco de código:
1: ...
2:
3: internal class TLSTestClass
4: {
5: private ClassWithHeavyProcess tp;
6:
7: internal void Test()
8: {
9: //UI Thread
10: tp = new ClassWithHeavyProcess();
11: tp.HeavyMethod();
12:
13: var bw = new BackgroundWorker();
14: bw.DoWork += BwDoWork;
15: bw.RunWorkerAsync();
16:
17: var bw2 = new BackgroundWorker();
18: bw2.DoWork += Bw2DoWork;
19: bw2.RunWorkerAsync();
20: }
21:
22: void BwDoWork(object sender, DoWorkEventArgs e)
23: {
24: tp.HeavyMethod();
25: }
26:
27: void Bw2DoWork(object sender, DoWorkEventArgs e)
28: {
29: tp.HeavyMethod();
30: }
31: }
32: ...
Veamos como implementar la clase ClassWithHeavyProcess.
Como primera aproximación podemos hacer algo así:
1: internal class ClassWithHeavyProcess
2: {
3: [ThreadStatic]
4: public static NeededForThreadProcess _neededForThreadProcess;
5:
6: static ClassWithHeavyProcess()
7: {
8: _neededForThreadProcess = new NeededForThreadProcess { Name = "Andoni" };
9: }
10:
11: public void HeavyMethod()
12: {
13: _neededForThreadProcess.Name = "Assigned from the thread with id: " + Thread.CurrentThread.ManagedThreadId;
14: }
15: }
Uno de los problemas de esta implementación, es que la inicialización de la variable, al estar implementada en el constructor estático solo se ejecuta una vez. Este escenario nos funcionará solo para el primer hilo, puesto que todos los demás accederán a dicha variable con un valor por defecto del tipo (nulo en los tipos por referencia).
Si no tenemos en cuenta esta circunstancia podemos obtener una bonita System.NullReferenceException como la obtiene el código aquí mostrado…
Como a grandes males, grandes remedios, podemos crearnos una propiedad que encapsule el acceso al campo e inicializarlo si está a nulo, es decir, si estamos en un hilo que no posee su propia copia de la variable.
Entonces tendríamos algo así:
1: internal class ClassWithHeavyProcess
2: {
3: [ThreadStatic]
4: public static NeededForThreadProcess _neededForThreadProcess;
5:
6: public NeededForThreadProcess NeededForThreadProcess
7: {
8: get
9: {
10: if (_neededForThreadProcess == null)
11: _neededForThreadProcess = new NeededForThreadProcess();
12: return _neededForThreadProcess;
13: }
14: }
15:
16: public void HeavyMethod()
17: {
18: NeededForThreadProcess.Name = "Assigned from the thread with id: " + Thread.CurrentThread.ManagedThreadId;
19: }
20: }
Tened en cuenta que cuando un hilo completa su procesamiento es eliminado y liberados sus recursos, incluida la copia de la variable asociada. (Si el GC ha decidido llevárselos al más allá…).
Bueno, esto es así casi siempre…
Recordad que desde el .NET Framework 2.0 existe el ThreadPool. De las optimizaciones que el .NET Framework haga sobre el pool de hilos manejados también nuestras aplicaciones se verán beneficiadas, puesto que si reutilizamos los hilos también sus variables de almacenamiento local. Esto es una mejora en el rendimiento, pero debemos asegurarnos que inicializamos correctamente las variables al inicio del procesamiento, puesto que pueden ser parte de algún hilo reciclado.
Si os preguntáis porque os cuento esto, tened en cuenta que si revisáis la implementación de la clase TLSTestClass podéis comprobar que está empleando objetos BackgroundWorker que internamente negocian con el ThreadPool de .NET.
Con respecto a este escenario el .NET Framework 4 ha evolucionado para hacernos las cosas aún más fáciles. Se ha incluido la clase genérica ThreadLocal (que ya existía en Java, sí…) que se encarga de encapsular el poco “pipeline” que nos quedaba por hacer a nosotros.
Con ella podemos evitar la propiedad y especificar el constructor que deberá invocar cuando lo necesite.
Con esta clase nuestro código podría quedar tan elegante como este:
1: internal class ThreadProcess
2: {
3: ThreadLocal<NeededForThreadProcess> NeededForThreadProcess = new ThreadLocal<NeededForThreadProcess>(() => new NeededForThreadProcess());
4:
5: public void HeavyMethod()
6: {
7: NeededForThreadProcess.Value.Name = "Assigned from the thread with id: " + Thread.CurrentThread.ManagedThreadId;
8: }
9: }
Realmente elegante!
Si implementáis esta funcionalidad porque desde la clase NeededForThreadProcess gestionáis algún recurso no manejado (uno de los escenarios que comentaba antes), recordad que es responsabilidad vuestra liberad dichos objetos. Esto lo debéis realizar al menos al destruir los objetos (sino antes) que los consumen, pero eso, como el valor en la mili, se os supone..
Es muy interesante observar como ciertos paradigmas van calando en la comunidad de desarrollo. Raro es ver hoy en día alguien que no defienda un modelo ágil de trabajo, puesto que sus virtudes son evidentes.
Como siempre ocurre, sabemos donde queremos ir, pero en ocasiones el camino no es lo suficientemente claro para avanzar sin dudas. Muchos son los que se pierden por diversos motivos echando a andar sin tener correctamente interiorizados los principales valores innegociables. Una vez conseguidos los mismos, lo demás vendrá solo.
Te puedes quedar, como dice un amigo, “Buscando por donde le entra el agua al coco…”
Si no afrontamos la adopción de una nueva metodología con la importancia que se merece, podemos cometer algunos errores que nos condenen al fracaso, y esto de verdad que minará la posibilidad de mejora para una larga temporada…
Algunos de los errores más comunes que nos pueden llevar a tener un SCRUM sesgado y poco efectivo pueden ser:
- No integrar los hitos heredados en la planificación del Backlog
Las empresas (aunque sea a golpe de ASM) hacen cosas en el día y a día. Asumen compromisos que deben cumplir. Un cambio en la metodología es una evolución, no una revolución. Deben contemplarse los hitos anteriores y encajarse en el nuevo modelo de manera natural. De nada (positivo) vale crear un sprint si el día 1 del siguiente mes debemos entregar la “master” y ese trabajo no se contempla en la planificación de Backlog.
- Jugar con dos barajas con las prioridades
Las prioridades y urgencias son las mismas con y sin SCRUM. La nueva metodología no va a solventarnos por arte de magia los problemas, solo nos va a dar unas reglas para afrontarlos. De nada vale planificar algo para saltarlo, haciéndonos trampas al solitario y andar como pollo sin cabeza apagando fuegos.
- Asumir de manera parcial o sesgada las reglas del juego
Una de las ventajas que tiene SCRUM frente a otras metodologías más predictivas, es su sencillez y empatía con el desarrollador. Estos al fin y al cabo son el motor de cualquier empresa de desarrollo de Software y colocarlos en el centro del tablero es una de los principales aciertos. Eso si, si te decantas por SCRUM implanta al menos las pocas reglas en conjunto para que la mecánica tenga sentido.
- Presencia de roles satélites o heredados
Al ganar visibilidad inevitablemente afloraran roles a los que se les verá el cartón. Quedará patente lo poco que aportan a día de hoy y serán grandes enemigos del cambio. Supervivientes hay en todos los sitios y tirar de la manta no les va a hacer ninguna gracia. Debemos identificarlos y recolocarlos si es posible puesto que pueden hacer mucho ruido en contra y comprometer la estabilidad. Siempre es más fácil deshacer que hacer.
- Permitir implantar la metodología sin conciencia Top-Down
Asumir una metodología (más siendo ágil) es un cambio profundo para una empresa. Afecta a todos los estratos de la misma y solo triunfará si se asume una conciencia global de la necesidad e implicación necesaria para el éxito. O jugamos todos o rompemos la baraja y no vale ir de farol ;)
- Establecer un ámbito de actuación de la metodología reducido o para partes de los equipos
Todo lo que ganemos en agilidad, es un éxito, pero los avances se multiplican y crean sinergias muy positivas cuanto mayor es el dominio se implantación de la misma. Asumirla en equipo muy estancos obliga a realizar un esfuerzo titánico por parte de unos pocos y no fomenta el ROI de las inversiones.
- Impedimentos de Hardware, limitación de inversiones
las herramientas no son parte de la metodología en si misma, sino la forma de implementar la misma. Olvídate de reinventar la rueda, existen herramientas muy poderosas que te permitirán a un coste asumible ser muy productivo. Con la aparición del Cloud Computing dichos costes pueden ser todavía más elásticos permitiendo a pymes y empresas con pocos recursos contar con las mismas herramientas que antes solo estaban al alcance de las grandes. SAAS de TFS es un buen ejemplo de este escenario.
- Intentar implantar todas las best-practices a la vez
Es mucha la gente que piensa que un conjunto de best-practices relacionadas con el mundo del desarrollo del Software son parte de SCRUM. Esto no es así. Está claro que cuanto mejor desarrollemos, mayor ventaja competitiva tendremos. Esto es independiente de la metodología que empleemos. Tanto en CMMI , RUP o MSF realizar pruebas unitarias, builds automatizadas, patrones de diseño…son prácticas muy valoradas. Es verdad que en aspectos ágiles todavía son más relevantes puesto que el intervalo de entrega se acorta (valor solo entendido como Software potencialmente entregable) pero esto es la guinda del pastel.
- Falta de paciencia y fe en los resultados
Como ya hemos comentado, no existe una varita mágica que nos resuelva los problemas. Solo con trabajo y esfuerzo llegarán los frutos. Es un proceso continuo, sin un fin definido. Siempre podremos ir mejorando y adaptándonos a las nuevas realidades que surjan por el camino. Si te decides a implantar SCRUM no esperes que al terminar el primer Sprint tu empresa se otra. Valora si es un poco mejor de lo que lo era antes. Evalúa la tendencia, no (solo) la foto y por supuesto, replantearte continuamente los procesos, identifica las acciones en cascada y disuélvelas con una integración más orgánica.
Estos son algunos de los puntos sobre los cuales debemos poner el foco a la hora de intentar implementar cualquier metodología en una empresa. Aunque son problemas comunes se acentúa aún más cuando deseamos trabajar con metodologías ágiles.
Por cierto, la palabra ágil no está empleada por que sí. Para que el conjunto sea ágil todos los componentes del mismo deben serlo. Esta necesidad nos obliga a identificar los puntos que no lo son y tratarlos como impedimentos (teoría de los cuellos de botella). Este proceso de mejora continua es el que nos permite adquirir agilidad puesto que los valores absolutos no tienen cabida en este marco.
Tanto en el mundo real como en digital en raras ocasiones podemos encontrar un escenario de negociación de más por más. Como ya sabemos es mucho más frecuente encontrarnos con un más por menos. Es habitual tener que negociar hasta llegar a un equilibrio entre las partes que componen un sistema. Las ecuaciones que gobiernan el universo del desarrollo de software se componen de variantes como rendimiento, coste de desarrollo, coste de mantenimiento, escalabilidad...que deberemos equilibrar para llevar al proyecto a buen puerto.
La distribución es uno de esas variantes. De echo es una de las más representativas. Desde el primer momento debemos tener en cuenta que distribuir objetos no es gratuito. Esta característica es atractiva por poderosa pero conlleva un alto impacto en el coste de desarrollo y mantenimiento así como en el rendimiento. Desde el punto de vista de arquitectura, debemos tener en cuenta las implicaciones de la distribución y valorar de manera "aséptica" todas las alternativas. Muchas veces he visto diseños que se podrían definir como "Sueño del arquitecto, pesadilla del desarrollador".
Una regla sencilla puede ser "No distribuyas nunca la aplicación". Si el mundo fuese un "poco" más simple y esta regla fuese válida en cualquier circunstancia, asunto terminado. (Me ha dado un escalofrío solo de pensarlo...).
Por lo tanto en ocasiones debemos distribuir de manera obligatoria, pero cuando?
Básicamente cuando no nos quede más remedio, como por ejemplo:
- Una de las separaciones más obvias es la tradicional entre clientes y servidores de software.
Los PCs son diferentes nodos y comparten repositorios de datos. Esto nos obliga a separara procesos que se comunican, siendo cliente/servidor la típica división entre procesos.
- Una segunda división ocurre a menudo entre la parte servidor de las aplicaciones y la base de datos (esa gran desconocida...)
Por supuesto puedes hacer correr tu aplicación en el mismo proceso de la base de datos utilizando elementos como procedimientos almacenados, pero en muchas ocasiones esto no es practico (por decirlo de alguna manera...). Debemos tener en cuenta que aunque el servidor y la base de datos corran en la misma máquina, lo hacen en procesos diferentes. Una vez que debemos comunicar diferentes procesos pagamos la mayor parte del coste de la distribución.
Por supuesto los servidores de SQL están diseñado para estas practicas de modo que podamos minimizar el coste.
- Otra clásica separación en procesos suele ocurrir en los sistemas Web entre el Servidor Web y el Servidor de Aplicaciones. Normalmente asociado a aspectos de seguridad relacionados con exponer al exterior solo la parte Web reduciendo así la superficie de ataque posible.
- Emplear paquetes de software hace frecuente tener que realizar distribuciones entre procesos por las diferencias entre los proveedores. En ocasiones utilizan sus propios procesos así que de nuevo estamos distribuyendo.
- Por último puede existir razones de peso por las que es necesario dividir el software de servidor. Eso sí, debemos asegurar muy bien de que es estrictamente obligatorio. No nos queda otra que dividir nuestro software en componentes remotos con interfaz de grano grueso. No vamos a hacer las mismas llamadas que si no estuviese distribuido, verdad...??
Si tienes dudas sobre esto, puedes continuar leyendo sobre el tema en SOA != Client Server + WCF
Como conclusión podemos decir que distribuir es una característica muy potente pero con un lado oscuro del cual debemos siempre tener en cuenta. Siendo conscientes de las implicaciones y valorando los riesgos podemos hacer llegar nuestro software hasta cotas más exigentes.
Cada día escuchamos más y más hablar de Cloud Computing. La evolución del mundo del desarrollo marca una clara tendencia debido a las múltiples beneficios que este paradigma aporta. Vamos a revisar los principales conceptos de manera muy sintetizada de tal modo que podamos aprender con las ideas claras.
Una cosa que debemos tener en mente es que el Cloud Computing es un paradigma en evolución. Por lo tanto, sus definiciones se encuentran sujetas a debate por parte de todos los actores implicados. Estos (está de mas decirlo) pretenden arrimar el ascua a su sardina, pero eso es harina de otro costal...
Basándonos en las definiciones del National Institute of Standards and Technology, Cloud Computing es un modelo para habilitar acceso remoto y bajo demanda a un conjunto de recursos computacionales (redes, servidores, almacenamiento, aplicaciones y servicios) que puedan ser rápidamente aprovisionados y liberados con un mínimo esfuerzo de gestión o interacción con el proveedor de servicios.
De manera estandarizada se especifican cinco características esenciales, tres modelos de servicio y cuatro modelos de despliegue. Vamos a revisar esos conceptos para componer una idea más completa.
Carcateristicas:
-
Auto-servicio bajo demanda
Un cliente puede aprovisionar de manera unilateral las capacidades computacionales en base a las necesidades, sin requerir interacción humana con cada proveedor de servicios.
-
Amplio acceso a la red
Los recursos están disponibles a través de la red y accedidos a través de mecanismos estándar que propician el uso desde plataformas heterogéneas.
-
Pool de recursos
Los recursos computacionales del proveedor son sirven a múltiples clientes empleando un modelo multi-tenant, con diferentes recursos físicos y virtuales
dinamicamente asignados y reasignados en base a las demandas del cliente.
-
Rápida elasticidad
Los recursos pueden ser rápida y elasticamente aprovisionados, en algunos casos de manera automática. Esta característica permite escalar (aumentar y reducir) rápidamente. Desde el punto de vista del cliente los recursos son ilimitados y pueden ser contratados en cualquier momento y en cualquier cantidad.
-
Medición de servicio
Los sistemas de Cloud automáticamente controlan y optimizan los recursos.
El uso de los recursos puede ser monitorizado, controlado y reportado aportando transparencia tanto para el proveedor como el cliente del servicio.
Modelos de despliegue:
- SaaS (Software as a Service)
Hace referencia a proveer la capacidad al cliente de utilizar las aplicaciones del proveedor que se están ejecutando en la infraestructura de la nube. Es importante tener en cuenta que el cliente no gestiona (salvo excepciones) la infraestructura subyacente de la nube.
Este es el modelo principal de Azure.
- PaaS (Platform as a Service)
Hace referencia a proveer la capacidad al cliente de desplegar sus aplicaciones sobre la infraestructura de la nube, creadas empleando los lenguajes de programación y herramientas soportadas por el proveedor. El cliente no gestiona la infraestructura subyacente de la nube pero sí que controla el despliegue de las mismas y posiblemente la configuración de los entornos donde estas son albergadas.
AppEngine de Google es un ejemplo de PasS
- IaaS (Infrastructure as a Service)
Hace referencia a proveer la capacidad al cliente de aprovisionar procesamiento, almacenamiento, redes y otros recursos computacionales sobre los cuales tiene la capacidad de desplegar y hacer correr software (puede incluir SO y aplicaciones). El cliente no gestiona la infraestructura subyacente de la nube, pero tiene control sobre el SO, almacenamiento, despliegue y ocasionalmente control (limitado) sobre ciertos componentes de la red. (Por ejemplo firewalls...)
Amazon AWS es el mayor proveedor mundial de IaaS.
Modelos de despliegue:
- Nube privada
La explotación de la infraestructura de la nube es realizada por una única organización. Puede ser gestionada por la organización o por un tercero.
- Nube comunitarias
La explotación de la infraestructura de la nube es realizada por varias organizaciones y soporta una comunidad que comparten ciertos aspectos (por ejemplo requisitos de seguridad, políticas...) Puede ser gestionada por las organizaciones o por una tercera parte.
- Nube pública
La infraestructura de la nube se encuentra disponible para el publico general o un gran grupo de industrias y es propiedad de una organizativo que comercializa los servicios de la nube.
- Nube híbrida
La infraestructura de la nube está compuesta por dos o mas nubes (privada, comunitaria o publica) unidas a través de estándares o tecnología propietaria que habilita la comunicación entre ellas
Espero que este pequeño resumen sirva para aclarar algunos conceptos básicos y genere un poco más de curiosidad.
El panorama actual en el mundo de desarrollo del software nos brinda más oportunidades de las que nunca habíamos tenido (quizás ni siquiera imaginado). Entre otros escenarios, la aparición de Internet ha propiciado el crecimiento de los sistema distribuidos, la orientación a servicios, el SaaS...
Este nuevo "el dorado" plantea características donde todas las empresas desean desembarcar sus activos. Por supuesto estos destinos son tan interesantes que muchos deciden tomar atajos para llegar a lo que creen el mismo destino, pero cuidado,
que como siempre, no es oro todo lo que reluce.
La formula del título viene a decir eso, se podría leer como:
SOA != Client Server + WCF
No es lo mismo desarrollar Software orientado a servicio que colocar una capa de WCF en una aplicación Cliente Servidor. Definitivamente NO ES LO MISMO...
Pero como ya sabemos las cosas no cambian solas, debemos como desarrolladores hacer un esfuerzo por ser conscientes de las nuevas reglas de juego con las que deseamos que nuestras aplicaciones den la talla.
Revisando mi experiencia el respecto podemos identificar los errores más comunes a la hora de crear Software orientadas a servicios:
- Los servicios (aunque no te lo creas) no están (solo) para ti.
Utiliza los recursos del servicio de manera razonable, piensa bien como y cuando realizar las llamadas evitando acaparar los recursos disponibles.
- Al consumir otros servicios estas realizando una llamada remota, eres consciente?
No hagas 17 peticiones con sus 17 serializaciones para pintar una pantalla. No me digas que son las clases que usas como DTO y que te van para el pelo para tu ORM...
Todo el tiempo invertido en optimizar la comunicación tendrá un alto ROI, te lo aseguro.
Por supuesto recibir 26 millones de objetos (bien serializados) es un problema a nivel de diseño de la aplicación. (consolida la información, pagina, trabaja por bloques pero no tires por ese camino bajo ningún concepto...)
- Siempre piensa en que la disponibilidad nunca es del 100%
Eso es así aunque algún comercial se empeñe en decir lo contrario.
Pregúntate que ocurre si el servicio no está disponible y dota a tu aplicación de la inteligencia necesaria para responder ante tal situación de manera digna. Siempre es interesante valorar la posibilidad de realizar las comunicaciones de manera asíncrona.
Ten en cuenta que no debes lanzar procesos que comprometan la estabilidad de los servicios, puesto que estos deben estar disponibles para los demás clientes.
(Recuerda que trabajar por bloques "casi nunca" es opcional y con determinado volumen de datos es obligatorio)
Piensa en la Alta disponibilidad, como hacer correr varias instancias en paralelo, clúster activo-pasivo antes de que te pille el toro...
- Diseña un plan de contingencia y déjalo por escrito
Si no quieres que la gente que mantiene la aplicación te llamen a las 3:00 de la madrugada por que se ha parado el servicio, dales los mecanismos oportunos para que operen con autonomía. Ten un poco de empatía y piensa que ellos no pueden controlar todas las aplicaciones que están en producción como los que lo han desarrollado.
- Escalabilidad no es solo una palabra más terminada en …idad
Creo que está de más decirlo, pero evitar mantener el estado en el servidor entre tus llamadas te permitirá escalar mejor. Tomate la molestia de planificar mecanismos de escalabilidad vertical y horizontal si no quieres morir de éxito. Corregir este tipo de problemas a posteriori siempre es traumático.
Ten en cuenta que todos los recursos son limitados, hasta el disco donde escribes el log se acaba si no tienes políticas de reciclaje. Piensa en que los servicios están diseñados para ejecutarse 24x7 y 365 días al año, en estos detalles debemos hacer especial énfasis.
- La correcta gestión de excepciones te puede salvar la vida
En relación con la disponibilidad, es crítico gestionar de manera lo más eficiente posible las excepciones. La tecnología está ahí hace tiempo solo debes esforzarte en aplicarla correctamente. Una excepción en un servicio debe gestionarse correctamente para que no comprometa su estabilidad y disponibilidad. Trabajar sobre ello puede mejorar mucho la QoS y reducir el coste de mantenimiento.
- Invierte tiempo en pensar bien tus contratos
Es importante ajustar el equilibrio entre la cohesion de los servicios y los clientes. Cuando desarrollamos orientado a servicio no debemos hacerlo ad-hoc a un cliente en particular. El servicio debe exponer una serie de funcionalidades bien definidas. Extendiendo esta característica conseguimos el correcto grado de cohesión.
Ahora tampoco hagas que usar tus servicios sea un infierno...
- Piensa bien cual es la mejor manera de establecer la comunicación con tus servicios
La serialización y transporte de los objetos es una parte muy significativa del tiempo de procesamiento consumido. Piensa cuidadosamente la manera de exponer tus servicios al mundo. expón los endpoints que sean necesarios y afina los behaviors de los mismos para evitar matar moscas a cañonazos.
Como siempre, se hace camino al andar, así que la resolución de los problemas presentes en este tipo de escenarios también tenderá a converger (para estandarizarse más adelante) mientras todos maduraremos en el proceso.
Por supuesto surgirán nuevos problemas relacionados con llevar el mundo del desarrollo de software más allá, que para algo estamos aquí, no?
Como los más viejos del lugar ya conocen, los bloques #if/#endif han sido empleados para generar diferentes builds a partir del mismo código fuente. Personalmente nunca he estado muy orgulloso con este mecanismo, complicaba la legibilidad del código y desperdigaba las llamadas. Dichas (malas) características aumentan el coste de mantenimiento y crean un mecanismo demasiado fácil del que abusar.
Aunque lo tenía en la lista de enemigos hasta hace bien poco no le había dedicado el tiempo necesario para buscarle alternativa, pero eso ya acabó...
El escenario típico antes de emplear dicho atributo era:
1- Crearse el método entre ambas directivas #if/#endif
2- Incluir también cada una de las llamadas al mismo entre una pareja de directivas #if/#endif (teniendo que crear más código fuente que la propia llamada...)
El sustituto es el atributo Conditional.
Veamos un código de ejemplo:
[ Conditional( "DEBUG" ) ]
private void Comprobar( )
{
...
}
Elegante, verdad? Al decorar el método con el atributo condicional, es el compilador, el que en base a las variables de entorno, decide si se realizarán las llamadas o no, obteniendo
Con "DEBUG"
public string Nombre
{
get
{
Comprobar( );
return _nombre;
}
set
{
Comprobar( );
_nombre = value;
Comprobar( );
}
}
Sin "DEBUG"
public string Nombre
{
get
{
return _nombre;
}
set
{
_nombre = value;
}
}
El contenido del método Comprobar no varía, solo las llamadas al mismo son modificadas. El único coste que pagamos es el espacio de disco consumido con la función "Comprobar". Debemos tener en cuenta que la función no será cargada en memoria y compilada JIT a menos de que sea llamada.
También podemos crear métodos que dependan de más de una variable de entorno:
[ Conditional( "DEBUG" ), Conditional( "TRACE" ) ]
private void Comprobar( )
{
…
}
Observar que ambos atributos son combinados por "OR", si queremos combinarlos por “AND” debemos utilizar #if/#endif:
#if ( DEBUG && TRACE )
#define AMBOS
#endif
De ahí la (casi) muerte al #if/#endif
En numerosas ocasiones hemos hablado de las características básicas que debe poseer cualquier aplicación profesional de software que desarrollemos. Una de las fijas en todos los listados es la estabilidad. Cuando valoramos dicha cualidad debemos ser conscientes de que nuestras aplicaciones no se ejecutan solas ni son independientes de los devenires del los usuarios a nivel del Sistema Operativo.
Revisando las posibilidades que manejamos a la hora de mantener nuestra aplicación siempre en un estado controlado nos podemos alegrar una vez más de contar con un framework estable y maduro como es .NET.
Imaginemos el siguiente escenario:
El usuario trabaja con nuestra aplicación editando una serie de datos de un determinado registro. Por otro lado, el Sistema Operativo comienza a descargar e instalar unas actualizaciones que obligan a reiniciar. El usuario acepta el reinicio sin darse cuenta que no ha salvado los datos… (improbable, verdad? ;))
Si no contemplamos este tipo de casuísticas en nuestra aplicación, esta se cerrará y la modificación no se reflejará en el sistema de almacenamiento subyacente (base de datos, archivos…) y se terminó la historia. Otro debate es si la culpa de la pérdida es nuestra o no, pero lo que es seguro, es que existen entornos en los que esta respuesta no es aceptable…
Para controlar cosas como estas (está todo pensado…) debemos trabajar con las posibilidades que nos brinde la clase Application de .NET. Entre otras características, esta clase nos brinda la oportunidad de interactuar con un cierre de sesión a través de un método sobrescribible o suscribiéndonos a un evento.
Vamos a ver este código:
1: public partial class App : Application
2: {
3: private bool _editing = true;
4:
5: protected override void OnSessionEnding(
SessionEndingCancelEventArgs e)
6: {
7: base.OnSessionEnding(e);
8: if (_editing)
9: {
10: e.Cancel = true;
11: MessageBox.Show("You can´t " +
e.ReasonSessionEnding.ToString() +
" with unsaved data.");
12: }
13: }
14: }
Estableciendo en este punto nuestras políticas, podemos determinar de una manera muy sencilla si el estado de nuestra aplicación permite realizar el cierre sin comprometer su estabilidad o datos almacenados en memoria. Si os interesa conocer el motivo del cierre de la sesión podéis consultar el valor de la propiedad ReasonSessionEnding de la clase SessionEndingCancelEventArgs
A veces cuesta muy poco dar superar lo estrictamente obligado, con lo que transmitimos una mayor sensación de esmero y profesionalidad.
Siempre es importante aprender de los demás (sobre todo de los buenos ;)) pero en aspectos como la organización y la metodología lo básico está inventado. Nuestra tarea como desarrollador consiste, básicamente, en aplicar esas buenas ideas a nuestra realidad y hacer que se ajuste a la misma como un guante.
Por supuesto, esta idea es más sencilla de decir que de poner en practica. Se deben tener en cuenta muchos aspectos, sin descuidar ni uno solo de ellos, si queremos tener un “Jelled Team” como lo califican en Peopleware. En el proceso ALM podemos observar que contar con un buena herramientas nos puede facilitar mucho el proceso.
Cuando comenzamos con una metodología, la herramienta seleccionada nos brinda una gran ayuda poniendo a nuestra disposición todo el know-how analizado y sintetizado para generarla. Y esto no es poco. Nos ayuda a encauzar la energía y optimizar los esfuerzos sin dispersarnos en decidir como comenzar a caminar en la organización básica del complicado mundo del desarrollo del software.
En este punto es donde, ante el Team Foundation Server hay que quitarse el sombrero. Para ser una herramienta relativamente moderna ha sabido encajar las piezas con mucho acierto abriendo los puntos claves a diferentes metodologías para elegir nuestro sabor preferido. (MSF, SCRUM…)
Como muestra un botón. Cuando en el TFS2010 reportas un bug sobre un proyecto, el formulario correspondiente (y la Web del Team Web Access !!) nos aparece un botón con la leyenda Tools. Al desplegarlo, tenemos entre otras opciones, la de mostrar el diagrama de estados de la gestión de bugs definida por la guía de proceso seleccionada.
Dicho elemento se ve así con el SCRUM de Cochango:
Cualquier desarrollador de Software se puede dar cuenta que poco tenemos que inventar al respecto. Como mucho, tendrás que hacer algún ajuste personalizado para tus particularidades. Ahora imaginaros la cantidad de horas y energía que podíamos malgastar en intentar crear una gestión de bugs como esta desde cero (más el tiempo en crear el diagrama y mandarlo al departamento de calidad ;)). Aspectos como este, transmiten madurez por parte de la herramienta, generan confianza en su uso y crean una sinergia entre los desarrolladores y la herramienta que nos ayudan a ser lo más eficientes posible.
A ver quien se vuelve al Source Safe ;)
Como ya más o menos todos conocéis LINQ to SQL implementa una política de concurrencia optimista. Esta característica parte de la premisa de no realizar ningún bloqueo sobre los registros con los que estamos trabajando. Este modo es el recomendado, y en ocasiones el único aceptable, sobre todo en entornos de alta escalabilidad como son por ejemplo las aplicaciones Web.
Cuando nos creamos el modelo de nuestra aplicación a partir de la base de datos, generamos un fichero dbml. Es importante tener en cuenta que, entre otras propiedades, podemos especificar como queremos que el contexto gestione el UpdateCheck de cada columna. (Always, WhenChanged, Never).
Esto nos permite, en base a la naturaleza de la información de un campo, afinar la política de comprobación de la concurrencia que deseamos aplicar. Por ejemplo, podemos sobrescribir siempre la descripción detallada de un producto (sin importarnos si otro usuario la ha modificado desde que leímos ) pero puede no ser aceptable para, por ejemplo, el Stock asociado al mismo. Esta característica junto con el RowVerison nos permite detectar los problemas de concurrencia y automatizar su resolución en la medida de lo posible.
Hablando con un equipo de desarrollo me contaban que tenían problemas al borrar un registro. Revisándolo con ellos, me comentaban que pasaban por parámetro clave primaria del registro que deseaban eliminar.
El código que empleaban era similar a este:
1: using (xxxDataContext ctx = new xxxDataContext())
2: {
3: Table1 t1 = new Table1 { Id = id };
4: ctx.Table1s.Attach(t1);
5: ctx.Table1s.DeleteOnSubmit(t1);
6: ctx.SubmitChanges();
7: }
Y el error que percibían era que no se eliminaba el registro asociado en la base de datos pero no sabían exactamente porqué...
Al revisar la política de UpdateCheck de las columnas de la entidad, me di cuenta que estaban definidos en el modelo con su valor predeterminado. (Always). Por lo que la cosa estaba clara, Linq To SQL estaba creando la consulta que lanzaba al proveedor subyacente concatenándole el valor original y al no encontrar dicho registro en la base de datos no eliminaba nada…
Al comprobar mi teoría veo que la sentencia que genera Linq To SQL para el borrado incluye una clausula where del estilo ...
DELETE FROM [dbo].[Table1] WHERE 0 = 1
¿¿0=1??
Para darles respuesta les comenté el problema y la solución fue tan simple como cambiar el UpdateCheck a Never puesto que este escenario les cuadraba para dicha tabla, pero yo ya me había quedado mosca con el tema del 0=1...
Leyendo un poco descubro que es una optimización generada por el equipo de ADO.net puesto que determinan que nunca se cumple la condición. Y la condición que nunca se cumple es la siguiente:
En la base de datos existe un campo Name que esta definida como NOT NULL, por lo tanto nunca puede almacenar un valor NULL (obvio, no?). En .Net el tipo de la propiedad que mapea a dicho campo es de tipo String y por la naturaleza del mismo este puede almacenar un NULL. De hecho es los que almacena si nos fijamos en el código superior.
Como LINQ To SQL observa que en el objeto el valor es un NULL y en la definición del esquema de la base de datos este valor no puede estar presente, determina que no va a coincidir por lo que optimiza con el 0=1...
Bueno dicho (y comprendido) queda...
Cada día están más en auge las metodologías orientadas a la productividad personal. Todos y cada uno de nosotros gestionamos recursos, al menos nuestro tareas en el tiempo, y es recomendable, por no decir necesario, organizar dichas tareas para ser los más productivos posible.
El ámbito de aplicación GTD no se limita al entorno profesional sino que cubre también los aspectos de organización personales, permitiendo aplicar pautas a todos los aspectos de nuestro comportamiento. Existen en la red toneladas de material al respecto y discutir las bondades de la metodología GTD y las implementaciones de las mismas quedan fuera de la intención de este post. Sin embargo, me gustaría analizar la relación que existe entre dos mundos íntimamente relacionados (aunque no de manera explicita) como son GTD y las metodologías ágiles. Como representante de dichas metodologías estudiaremos Scrum.
Si consideramos GTD como un interfaz o contrato, llamémosle IGTD, sus puntos serian:
- Recopilar
- Procesar
- Organizar
- Revisar
- Hacer
Veamos como SCRUM implementa cada uno de los mismos…
- Recopilar
El objetivo en GTD se define como “sacar” todo de nuestra mente y recogerlo en alguno de los elementos de almacenamiento para luego procesarlos.
Scrum define exactamente esta tarea identificando un rol para cubrirla, el responsable de producto o Product Owner. Entre las responsabilidades principales de dicho rol se encuentran la de identificar los puntos que más valor aportan al producto servicio que desarrolla el proyecto. Dicha recolección se realiza escuchando y tratando con los diferentes stakeholders. Este punto común de acceso permite crear una capa de protección y homogenización para el resto del equipo.
Otra tarea muy importante y a la vez menos visible que recae sobre esta figura, es la de rechazar las propuestas de los stakeholders que no interesa avancen por el flujo puesto que no son interesantes para el producto. Esto permite al equipo centrarse en lo que realmente aporta valor.
- Procesar
Por supuesto, el trabajo de un buen Product Owner, no se limita a transcribir todo lo que escucha a los diferentes stakeholders. Debe realizar un proceso de análisis y diseño cuyo resultado se muestra como un conjunto de historias de usuario o Product Backlog. Dichas historias deben mantenerse consensuadas, consistentes y priorizadas puesto que conforman el material sobre las cuales trabajará la “apisonadora” que es el equipo.
Una buena regla para saber si tienes un buen Product Owner en tu equipo es preguntarse cuanto disminuiría la rentabilidad del producto si lo sustituyes por una regla de redirección de correo…
- Organizar
El equipo, liderado por el Scrum Master y contando con la disponibilidad del Responsable de Producto, comienza en el Sprint Planning Meeting a digerir y desmenuzar ese producto Backlog. El resultado de dicho procesamiento son las tareas necesarias para cubrir las historias de usuario que el Product Owner ha recopilado.
- Revisar
Scrum da gran importancia al proceso de revisión. En base al grano deseado realiza la tarea de revisión en dos maneras.
Todo el equipo se reúne una vez al día en el Daily Scrum comenta lo que ha realizado, lo que va a realizar en el día y los impedimentos que se ha encontrado por el camino. La verdad es que no se me ocurre una mejor forma de aplicar el concepto de revisión a grano fino.
Por otro lado, al finalizar cada sprint se realiza una revisión del mismo, Sprint Retrospective que permite a nivel de todo lo realizado en el Sprint, evaluar los aspectos positivos para potenciarlos y negativos para mejorarlos.
En GTD también existen dos tipos de revisiones, las diarias y las semanales (por Sprint para Scrum) así que en este punto la cosa encaja como un guante.
- Hacer
Una vez que tenemos claro lo que hay que hacer el equipo lo desarrolla, lo mismo que en GTD. Ambas metodologías hacen hincapié en la satisfacción de hacer las cosas y poder marcarlas como hechas, quitándolas de la primera línea de batalla y permitiendo centrarnos en lo que falta por hacer.
La conclusión que podemos obtener de este análisis, es que ambos metodologías son recomendablemente compatibles. Encajan porque se basan en patrones comunes, haciendo hincapié en centrarse en lo importante, reducir el stress, simplificar el día a día.
Además son especialmente cuidadosas con evitar el cambio de contexto y fomentar la concentración, GTD vía controlando las interrupciones internas y externas y Scrum blindando a los equipo de los cambios durante los Sprints.
Si os pregunto que manera de instanciar los objetos es más rápida, por código o vía el parser de XAML ¿Cual sería vuestra respuesta?
Pues la mayoría de los desarrolladores dirían que por código, pero obviamente la cosa tiene trampa…
En la mayoría de los casos el parser de XAML es más rápido. La razón de esta característica es el resultado de una serie de optimizaciones realizadas en tiempo de ejecución por Silverlight. El parser de XAML no crea los API objects que se emplean para interactuar con los elementos, sino que solo crea una representación interna de los mismos. Cuando desde código comenzamos a interactuar con esos objetos es cuando Silverlight crea los API objects necesarios. Esta característica se hace especialmente patente en inicializaciones de gran cantidad de objetos, aunque hay entra nuestra labor de diseño para evitar crear vistas inmanejables…
Teniendo esta particularidad en mente y valorando las facilidades de integración diseñadores/desarrolladores que nos da escribir UI en XAML es recomendable dejar la creación de objetos por código para los escenarios en los que realmente es necesario.
No digo nada nuevo al afirmar que las empresas de desarrollo de software cuentan como materia prima para crear sus “productos finales” con la tecnología y conocimiento. Ahora bien, este conocimiento no reside en el aire, sino en las personas.
Los malos modelos directivos valoran los recursos solo en su aspecto cuantitativo sin valorar la calidad de los mismos. He oído a “grandes” gestores del sector de desarrollo de software, sacar pecho al decir que consigue dos “recursos” (por ejemplo programador) al precio de uno. Por supuesto, el cambio implicaba sustituir una persona con diez años de experiencia por dos becarios, pero desde su perspectiva el cambio de 2x1 implicaba el doble de trabajo al mismo coste…
Este mercado avanza, lentamente y en su proceso madura. Podemos decir que el ritmo al que madura el mundo del desarrollo del software es varias veces más lento que el ritmo al que avanza la tecnología, pero aun así, lo hace. Si hiciéramos un paralelismo con algún otro sector de desarrollo más maduro, supongamos la automoción, nadie se plantearía trabajar sin una metodología definida que permita a todos los miembros de los diferentes equipos conocer las reglas del juego. Aún así hay muchas empresas que no emplean ningún tipo de metodología explicita.
Pensemos un poco sobre como impacta la forma de trabajar en la motivación de los profesionales. Los músicos de una orquesta, por muy buenos que sean, necesitan una partitura compartida para tocar juntos. Es cierto que la partitura ya esta creada por un compositor (en muchas ocasiones genios) y esta no varía. Se repite de idéntica manera miles de veces y no se adapta a las demandas del que la escucha. Nuestra partitura es más compleja. Varía con el tiempo y no es conocida de antemano (aunque las metodologías predictivas se empeñen en decir lo contrario). Al empezar nuestra obra no conocemos la cantidad de violines o tubas que necesitaremos…
Esta complejidad es una razón más para contar con una poderosa herramienta como la metodología que nos guie por el camino. Esta nos aporta:
- Evitar desgastarnos en definir y redefinir procesos implicados en el día a día.
- Aplicar cierta “objetividad” a la forma de trabajar y a la valoración del trabajo de los miembros del equipo.
- Ganar en visibilidad al definir roles y responsabilidades asociadas.
- Alinear los objetivos de los diferentes miembros del equipo.
- Tener una base que adaptar y mejorar para los siguientes proyectos.
Cualquiera de estas características son básicas a la hora de motivar a los profesionales, sobre todo a los buenos. He tenido experiencias al respecto y es un autentico fenómeno a estudiar como cambia la aptitud de los miembros de un equipo que trabajan sin ninguna metodología explicita, al implantar una metodología (especialmente las ágiles). Muchos de ellos tienen la sensación de que su trabajo no se valora porque no es visible, lo cual acaba implantando un “comunismo” asesino de la eficiencia.
Podemos decir que los buenos profesionales necesitan visibilidad y que la metodología aporta visibilidad…así que la cosa está clara.
Microsoft anunció ayer que comprará los activos relacionados con Teamprise de SourceGear LLC. Este software permiten a los desarrolladores usar el IDE de Eclipse (que opera en varios sistemas operativos, incluyendo UNIX, Linux y Mac OS X...), para construir aplicaciones que se comunican con Microsoft Visual Studio Team Foundation Server. Esta combinación permitirá a los desarrolladores utilizar una única herramienta para la gestión de ciclo de vida de proyectos con independencia de la plataforma de desarrollo.
Seguro esta característica va a permitir a muchos desarrolladores de mundos tan “separados” comenzar a unificar esfuerzos, reducir la brecha que nos separa y de paso hacer TFS más potente. Estoy deseando hablar con algunos Javeros muy interesantes que conozco a ver si les convenzo para probarlo.
Más información por aquí
Más artículos
Página siguiente >