domingo, 14 de agosto de 2011

Microsoft Magazine

Una forma de mantenerse actualizado

http://msdn.microsoft.com/en-us/magazine/default.aspx

"Sólo cuando se empieza a estar mar adentro nos damos cuanta de la inmensidad de el, adentrémonos pues en el mar"

viernes, 5 de agosto de 2011

Glosario


Esta es la liga de un glosario del NetFramework que nos servirá mas de una vez:


sábado, 16 de julio de 2011

Calidad en el software

Calidad en el software ¿Cómo lo logramos,qué medimos?
En teoría los sistemas deberían satisfacer un conjunto de requerimientos, y lo que muchas veces hacemos a un lado es que son esos requerimientos los que definen o mejor dicho deberían definir la arquitectura de nuestro sistema.

Es por eso que en este post quisiera resaltar la importancia de una correcta definición y categorización de los requerimientos.

He de decir que a lo largo de mi experiencia profesional he visto y vivido problemáticas en algunos proyectos por problemas de “calidad” en el software que estamos por entregar, ¿y esto que tiene que ver con los requerimientos y más aun con la arquitectura de nuestra aplicación? Todo, he de decir que todo.

A donde quiero llegar es que la calidad de nuestro producto que entreguemos a los usuarios dependerá de una correcta definición de los requerimientos (lo cual parecería obvio, pero a veces no lo es), y va mas allá de eso.

¿Cuántos de nosotros hemos estado enterados que existen normas y estándares para definir la calidad del software? Bueno espero que ya haya sembrado la semilla de la duda y de esa curiosidad que nos lleva a conocer nuevas y mejores formas de hacer las cosas, empecemos con la carnita.

Sabemos que un requerimiento es una característica de nuestro sistema y se dividen en funcionales y no funcionales.

Existe una norma / estandar (ISO/IEC 9126) que clasifica las características que debemos contemplar en nuestros sistemas de la siguiente forma


.-Funcionalidad :Indica las características que nuestro software debe cumplir y contempla: exactitud, seguridad, interoperabilidad y cumplimiento de normas y estándares.

En esta categoría incluimos las necesidades de negocio a satisfacer

.- Confiabilidad : Indica las capacidades de nuestro software de mantener un nivel de desempeño específico bajo condiciones definidas. Debe contemplar madurez, tolerancia a fallos y recuperación.

1. La madurez se refiere a que nuestro software no experimente interrupciones en el caso de errores internos.
2. Tolerancia a fallos indica la capacidad de controlar los fallos en función de mantener un nivel de comportamiento aceptable de nuestra aplicación.
3. Recuperación indica la capacidad de que nuestro sistema se recupere en caso de error.

En esta categoría deberíamos definir mecanismos de replica para nuestra base de datos, como es que nuestra aplicación apuntara de forma automática al nuevo servidor de BD, saber que nuestra aplicación debe estar disponibles cuantos horas y cuantos días al año.

.- Usabilidad : Indica la capacidad de que nuestro software sea intuitivo, y fácil de entender y usar por nuestros usuarios.

.- Eficiencia : Indica la capacidad de mantener un nivel de desempeño en términos de tiempos de respuestas y cantidad de recursos disponibles.

En esta categoría es donde deberíamos definir una “Baseline” para nuestra aplicación la cual define el comportamiento de nuestro aplicativo con “n” usuarios, con “X” cantidad de memoria, capacidad de red. Capacidad de procesador

.- Mantenibilidad : Indica la capacidad de nuestro software para ser modificado y tener un nivel bajo de riesgo de introducir errores, así como de que estas modificaciones sean fáciles de implementar.

En esta categoría deberíamos prestar atención especial al diseño de nuestras clases, componentes, capas, estilos de arquitectura a utilizar. Proyectos de pruebas unitarias a ser implementados.

.- Portabilidad : Indica la capacidad de que nuestro software sea potable entre plataformas y la capacidad de que coexista.




Como podran ver, el establecer correctamente los requerimientos de nuestro sistema seran el input que necesitamos para empezar a definir la arquitectura de la futura aplicación.



Hace un tiempo estuve involucrado en un proyecto que tenia al menos dos años en desarrollo, mantenimiento y entregas. Me entere en algún momento que el cliente cuestionaba entre otras cosas la usabilidad y parecía que la moda de haber echo un sitio Web no era la solución tecnológica por la que se debió optar, sin duda respondernos las preguntas que nacen de seguir la norma ISO/IEC 9126) habría evitado esa amarga experiencia.

Espero les sea de utilidad

viernes, 15 de julio de 2011

Publicar Servicio Web para Silverlight

Si te ha aparecido el siguiente error tratando de publicar tu aplicación Silverlight que utiliza servicios de WCF, esto quiza te pueda intersar

"
Se ha producido un error al intentar realizar una solicitud al URI 'http://localhost/XXXXX/XXXXXXX/XXXXXXService.svc'.
Puede deberse a un intento de acceso a un servicio de configuración entre dominios sin una política
entre dominios adecuada en contexto o una política no apropiada para servicios SOAP.
Es posible que necesite ponerse en contacto con el propietario del servicio para publicar un archivo de política
entre dominios y para asegurarse de que permite enviar encabezados HTTP relacionados con SOAP. Este error también puede deberse al uso de tipos internos en el proxy de servicios web sin utilizar el atributo InternalsVisibleToAttribute. Para obtener más información, consulte la excepción interna."

Sucede que Silverlight de forma predeterminada por seguridad sólo permite llamadas a servicios dentro del mismo dominio de la aplicación, un dominio de la forma http://Midominio.com unicamente podra acceder a servicios que esten dentro de ese mismo dominio, ejemplo:

.- Cuando estamos en nuestro ambiente de desarrollo muy probablemente los End Point de los servicios que estemos consumiendo esten apuntando a "localhost"












La configuración de nuestra referencia al servicio quiza se vea del tipo :



Cuando intentamos publicar nuestro sitio Web resulta que contrario a nuestro ambiente de desarrollo estariamos indicando el nombre del dominio o de nuestro servidor y entonces empezaran los problemas, nuestra aplicación sí iniciara pero el consumir los servicios no sera posible.

La solución a este problema es utilizar los mecanismos que Silverlight nos ofrece para acceder a servicios entre dominios que son:

1) Archivo crossdomain.xml válido
2) Archivo clientaccesspolicy.xml

Adicionalmente cuando publiquemos nuestro sitio publicado debera apuntar a "NOMBRESERVIDOR" pues aun cuando ellos esten en el mismo servidor y dentro de nuestro sitio Web tendremos un pequeño dolor de cabeza si continuamos utilizando "localhost". Al cambiar los End- point y la configuración de la referencia de servicio será suficiente para quitar este error y poder publicar nuestra aplicación web que consume servicios de WCF.

Aqui dejo unas referencias que a mi me ayudaron

http://msdn.microsoft.com/es-es/library/cc197955(v=VS.95).aspx

http://msdn.microsoft.com/es-es/library/cc197940(v=VS.95).aspx

SQL Server Denali

Esta puede ser una noticia no tan fresca para muchos y aunque esperaba que no tardara mucho he de decir que no me dejó de sorprender la noticia de que ya esta liberada la nueva version beta de SQL Server, denominada Denali.

Podran encontrar mas información en:

http://download.microsoft.com/download/d/9/4/d948f981-926e-40fa-a026-5bfcf076d9b9/Spatial_Denali_CTP1.docx

http://www.microsoft.com/sqlserver/en/us/future-editions.aspx


Por lo mientras un tema mas en que seguirse manteniendo actualizado.

sábado, 25 de junio de 2011

Beneficios de los Filegroups, un acercamiento

Hace poco mas de un año que fue la ultima vez que escribi aqui, en la entrada mas añeja hablaba de particionar indices y una tarea que esta intrinseca en ello es crear filegroups adicionales.
Este es un tema muy extenso y quisiera dar un acercamiento a los beneficios que obtendremos al crear Filegroups en nuestras Bases de Datos.

Es una mejor practica agregar Filegroups y Files adicionales a nuestras Bases de datos y tratare de resumir la explicación mas importante:

.-Al crear más de un Filegroup podremos tener una mejor administración de nuestros archivos en le futuro, ejemplo: Una vez que tenemos agrupaciones de archivos y tablas si existiera la necesidad de con el menor esfuerzo hacer que un conjunto de tablas estén sólo disponibles como lectura únicamente bastaría modificar un atributo(ReadOnly) al Filegroup al que pertenecen y así evitamos hacer cambios mayores y afectaciones a otros módulos y aplicaciones cuyas tablas estén ajenas a nuestro interés.

.-Al tener más de un Filegroup proveemos del mayor aislamiento posible I/O. Los datos en las tablas de Sistema de nuestra base de Datos no cambian tan frecuentemente como las tablas de usuario y al minimizar la escritura en el Filegroup Primary reducimos el riesgo de introducir daños a los archivos que lo conforman, es necesario mencionar que el estado del Filegroup Primary determina el estado de la Base de Datos, al tener más de Filegroup incrementamos la disponibilidad de nuestra base de datos porque estaremos minimizando los cambios hechos al Filegroup Primary.

.-Si en el futuro además de crear Filegroups adicionales, los archivos pudieran estar en unidades de disco separadas es posible crear una estrategia de almacenamiento / consultas tal que nos permita reducir los cuellos de botella I/O en el disco duro (Contención).