El grupo de usuarios BcnDev.Net ha preparado un concurso bastante interesante sobre Silverlight.
El concurso, a parte del reto personal que puede suponer, tiene premios bastante interesantes. El primer premio es un viaje al Mix de las Vegas en Marzo de 2008, con todos los gastos pagados ( viaje y estancia ). Pedazo premio!!!
Si queréis ver toda la información sobre el concurso podéis pinchar aqui. Merece la pena!!
El pasado 3 de octubre celebramos en Bilbao el evento «Exprime tus datos con SQL Server 2005 Reporting Services!!». Acudió bastante gente, unas 50, y aunque alguna demo se puso un poco tonta en general todo salió bien, o al menos eso intentamos.
Por si alguien está interesado, pongo las ppts y demos que se utilizaron.
En un post anterior ya comentaba que en Windows Communication Foundation ( WCF ) no es oro todo lo que reluce y algunas cosas me hacen reafirmarme en mi opinión. Hace poco tuvimos un «problema» con WCF que me dejó bastante contrariado. A continuación intentaré explicar lo que pasó.
Haciendo unas pruebas de carga sobre la aplicación web que estamos desarrollando nos dimos cuenta de que el rendimiento de la aplicación era bastante malo, porque cada vez que hacíamos una petición al servidor se lanzaba el compilador, el proceso csc.exe. Lógicamente, el rendimiento era malísimo porque el proceso csc.exe se quedaba con gran parte de la CPU, lo que hacía que se procesasen muy pocas peticiones.
Pero..¿ Por qué se lanza el compilador ? ¿ Qué sentido tiene ? En una versión release no le veo sentido por ningún lado….pero sí, sí tiene sentido.Y el sentido está en que usamos comunicación wcf entre la consola web y la lógica de negocio y en que en muchos casos se usan DataSets.
Cuando el cliente WCF genera el proxy para llamar al servidor automáticamente se crean clases con el atributo XmlSerializer para poder llamar al servidor.
El cliente, en tiempo de ejecución, por cada tipo de datos que es serializable y que usa XmlSerializer genera y compila código para serializarlo, lo que puede provocar un decremento importante en el rendimiento de la aplicación….y de hecho, eso está provocando.
Por tanto, aunque a nosotros se nos ha manifestado por usar DataSets, podría darse siempre que se usen tipo serializables con XmlSerializer.
Pero todo tiene solución y se puede cambiar este comportamiento y así evitar que se lance el compilador. La herramienta svcutil nos pérmite mejorar el rendimiento de nuestra aplicación generando el código de serialización necesario para nuestros tipos serializables evitando que esta operación se haga en tiempo de ejecución.
La secuencia a seguir es la siguiente:
Y ya está, ya no se vuelve a volver a ver el proceso csc.exe.
Como he comentado antes, esta situación podría darse en otras situaciones que no tengan nada que ver con los proxys wcf. Para estas situaciones existe otra utilidad llamada sgen.exe, que permite obtener la misma funcionalidad que hemos comentado, con la salvedad de que sgen ya genera directamente el assembly necesario para la serialización y no sólo el código fuente.
Para finalizar, comentar que aunque sea una situación normal la que he comentado, me parece bastante absurdo que sea una comportamiento por defecto. Esto sí que sigo sin entenderlo….
Desde hace un tiempo utilizo en el proyecto en el que trabajo Team System. Me parece un producto bastante interesante, y aunque no tiene todas las características que me gustaría, sí que ha mejorado nuestra forma de trabajar.
Una de las cosas que más me ha llamado la atención desde que empecé a utilizarlo es la cantidad de utilidades y add-in que han surgido desde la aparición de la primera versión…Muchísimas y muy útiles!!
La extensibilidad es una de las características más interesantes de Team System y en muchos foros he escuchado que es una característica diferenciadora, ya que cualquiera puede adaptar y ampliar la funcionalidad de este producto.
En una primera impresión estoy de acuerdo de que es una característica muy útil y potente, ya que permite hacer personalizaciones y añadir funcionalidad que la aplicación no tiene pero que necesitamos. Muchas de las aplicaciones que han salido las utilizo a diario e incluso Microsoft ha comprado algunas….como el caso de la consola web de TeamPlain.
Aún así, considero que la extensibilidad y todo lo que salido alrededor de Team System puede tener una cara oculta, una segunda lectura….
¿ Qué hayan salido tantas aplicaciones no puede significar que la primera versión de Team System salió muy verde ? ¿ No se puede llegar pensar que incluso ha sido una estrategia bien llevada por parte de Microsoft?
Desde el punto de vista estratégico parece una buena elección de Microsoft. Sacan una primera versión, que aunque floja es útil…son conscientes de que el producto no es lo bueno/completo que debería ser, que es una primera versión, pero lo hacen de tal manera que es fácil desarrollar nuevas funcionalidades….salen aplicaciones, ven en el mercado y en función de lo que se vaya usando deciden incluirlo o no en las siguientes versiones del producto, ya sea desarrollándolo, comprándolo o fusilando el código….
Aunque seguramante alguno piense que estoy viendo gigantes donde sólo hay molinos, en mi opinión algo de cierto puede haber en esto que comento, pero ojo, que con esto tampoco no quiero decir que el producto Team System sea malo, sino que está algo verde todavía y que tiene todavía mucho que mejorar….por lo que espero que las siguientes versiones sean mucho mejores. Yo al menos, a un producto como este, le pido más de lo que tiene actualmente.
«Exprime tus datos con SQL Server 2005 Reporting Services» es el nombre del próximo evento que vamos a celebrar en el grupo de usuarios del País Vasco, Artalde.NET.
El evento se celebrará el día 3 de octubre y como siempre, será en la universidad de Deusto, en la segunda planta del edificio ESIDE.
Agenda:
19:00 Registro
19:15 ¡Exprime tus datos con SQL Server 2005 Reporting Services
Introducción a Reporting Services
Diseño de informes
Subscripciones, caché, seguridad…
Integración de los informes en nuestras aplicaciones.
Control de informes por código.
En esta ocasión el ponente seré yo mismo….prometo que intentaré preparar algo que sea de interes para todos los asistentes…a ver qué me sale.
Si estáis interesados no dudéis en registraros.
Una de las características que me parece más interesante de Reporting Services es el sistema de subcripciones que posee.
De manera muy sencilla se pueden crear subscripciones a informes y por ejemplo, hacer que de forma automática el informe se genere por correo electrónico.
Me parece una característica muy interesante a la que le encuentro un montón de aplicaciones en la vida real. Por ejemplo, para mandar el típico informe ejecutivo que quieren recibir «los jefes» de forma periódico, para ver cuatro grafiquitos….Bueno, seguro que se os ocurren a vosotros muchos más..
Mediante la herramienta de administración del servidor de reportes se puede crear estas subscripciones. Una vez que tenemos nuestros informes publicados en nuestro servidor, podemos crear subscripciones a través de la interfaz web. Dentro de la subscripción podemos definir sus propiedades, como cuándo se debe generar o en qué formato. Por ejemplo, podemos querer que todos los días a las 00:00h se genere un informe en formato PDF y se guarde en disco o se mande por correo electrónico a nuestro jefe.
Pero si queremos integrarlo en nuestra aplicación también podemos. Desde código también es muy sencillo poder realizar cualquier de las operaciones que se hace desde la herramienta de administración. Reporting Services exporta servicios web que permite realizar cualquier de las operaciones que se nos puedan ocurrir.
Si queremos utilizarlo desde nuestra aplicación sólo tendremos que añadir una referencia web a http://<servidor>/reportserver/reportservice2005.asmx.
Una vez que hecho esto lo demás es coser y cantar. Sólo es necesario usar uno de los métodos que nos proporciona el servicio web.
public string CreateSubscription (
string Report,
ExtensionSettings ExtensionSettings,
string Description,
string EventType,
string MatchData,
ParameterValue[] Parameters
)
Además de este método, exporta numerosos métodos para hacer cualquier operación que se os ocurra sobre el servidor de reportes; crear una programación, listar subscripciones, crear una, borrarla, listar los reportes, obtener los parámetros que soporta un reporte etc,…practicamente cualquier cosa que se puede hacer desde la herramienta administrativa.
¿Cuántas veces habréis dicho o habréis oido esta frase en alguno de los proyectos en los que habéis trabajado ? «De momento se queda así, ya lo cambiaremos más adelante».
Debo reconocer que yo mismo he utilizado esta frase…..y también debo reconocer que luego nunca ( o casi nunca ) lo he cambiado….porque no nos engañemos, luego casi nunca se cambia.
Hace unos días, revisando un producto en el que he trabajado, me daba cuenta de varias cosas que habíamos hecho de manera «temporal» y que ahí seguían, tres años despues.
Una cosa debemos tener claro; si no tenemos tiempo durante el desarrollo..¿ cuándo lo tendremos ? ¿Una vez hayamos terminado el desarrollo vamos a deshacer los cambios temporales y vamos a mejorarlos? No lo creo.
Una vez se termina el desarrollo siempre priorizamos otras tareas….por ejemplo, si estamos en fase de certificación del producto vamos a considerar más importantes las incidencias que tengamos con el fin de tener una versión final lo antes posible.
Si estamos en fase de mantenimiento, seguramente prioricemos las incidencias de los clientes o si no tenemos incidencias, intentaremos no modificar nada de lo que ya funciona, para evitar fastidiar nada. Además hay que tener en cuenta que una vez entregado el producto y al cliente le va bien, seguramente estaremos empezando con algún otro proyecto que haga que no podamos dedicar tiempo al que acabamos de terminar.
Por estos motivos, considero que debemos tener cuidado con esta frase y evitarla lo máximo posible, intentanto afrontar estos cambios lo antes posible en la fase de desarrollo.
Si aún así, por algún motivo debéis hacer algo temporal y no hay otra alternativa, por ejemplo para una demo intermedia, una vez que termine esa demo afrontad los cambios sin demorarlos en el tiempo, porque si se demoran, no se hacen.
Una pregunta con la que me he encontrado ya en varias ocasiones es si es necesario tener un Report Server para poder usar informes en una aplicación .NET.
La respuesta es sencilla; no.
Visual Studio dispone de un control llamado ReportViewer que permite visualizar informes en dos modos; en modo local y en modo servidor. El modo local permite carga un fichero RDL desde un recurso local de la aplicación, sin necesidad de instalar ningún servidor adicional. El modo servidor permite acceder a un informe que se encuentre en un servidor de reportes y ser visualizado en la aplicación.
Sencillo….pero ¿ cuál debo usar ? ¿ Cuál es mejor ? Pues depende, ya que cada método tiene sus ventajas e inconvenientes.
Report Server
Ventajas
Inconvenientes:
Modo local
Ventajas
Inconvenientes
Con el lanzamiento del framework 3.0 de .NET se presentaba Windows Communication Foundation ( WCF ) como una verdadera revolución en el mundo de las comunicaciones.
En el número 37 de dotNetMania leía una entrevista a Ami Vora, Program Manager de .NET Framework 3.0, que decía:
«Creo que WCF es un API revolucionaria en muchos sentidos.Está pensada para facilitar la vida de los programadores, permitiendo que los programadores puedan mantener su foco en la lógica de la aplicación y no en las caracteristicas especiales que pueden necesitar como consecuencia de que la aplicacíón tenga que comunicarse con las demás.
Los programadores podrán añadir valor a sus aplicaciones haciendo que estén conectadas, de una forma sencilla, por una parte, y muy poderosa en sus posibilidades, sin tener que aprender distintas tecnologías en función del tipo de conectividad que se necesite en cada caso. Y todo esto sin importar el protocolo de comunicación, el lugar en donde tenga lugar esa comunicación o los mecanismos seleccionados en la transferencia.»
Ya llevo un tiempo trabajando con WCF y aunque sí que me parece una tecnología muy interesante y seguramente volvería a usarlo si empezara de un nuevo proyecto, no estoy de acuerdo con lo que se comenta en esta entrevista. No es oro todo lo que reluce.
Usar WCF no es tan sencillo como parece o como se dice. Es potente, sí, pero podríamos decir que en muchas ocasiones es demasiado potente. Esta potencia se vuelve contra nosotros y hace más complejo su uso.
Te dejar hacer cosas complejas de una manera «más sencilla» de como se podría hacer sin esta tecnología, pero en mi opinión se complica cuando lo que se quiere hacer no es tan completo. Si quieres hacer algo básico, sencillo, que no requiere de grandes aspavientos, no es tan sencillo como debería ser. En este punto creo que se ha optado por la potencia pero se ha olvidado que también debería ser sencillo de utilizar.
Podría ser como un Ferrari y un utilitario. WCF puede ser como un Ferrari, pero normalmente con un utilitario nos vale…Si para las situaciones habituales donde con un utilitario nos vale usamos un Ferrari las cosas se nos complican. Usar un Ferrari para ir a trabajar tiene que ser un poco complicado de aparcar. 🙂
He probado la «Web Service software Factory«, para ver si usándolo podría hacer más sencillo e intuitivo el uso de WCF pero nada. Está bien si se usa como referencia y para ver buenas prácticas a la hora de implementar una aplicación wcf, pero no pasa de ahí.
Por otro lado, tenemos que tener en cuenta que la gran mayoría de las decisiones de diseño y de arquitectura se toman en las fases iniciales del proyecto y entre estas decisiones se toman las decisiones referentes a las comunicacicaciones. Centrarse en la lógica de negocio olvidándonos de las comunicaciones se hace complicado y en muchos casos imposible. Por ello, aunque WCF te da una gran flexibilidad para cambiar la forma de comunicarse las aplicaciones rara vez se hará uso de esta flexibilidad.
Por último, tampoco considero que WCF nos abstraiga de las comunicaciones. Tienes que conocer muchos aspectos de las comunicaciones para poder hacer el diseño o la arquitectura de la aplicación y conocer bien cómo hacer funcionar correctamente un servicio; service Throttling, funcionamiento de las instancias, el manejo de sesión etc…
Por tanto, al «Cesar lo que es del Cesar». WCF es una tecnología interesante y potente, pero a la que en mi opinión le falta todavía algo para ser esa tecnología de la que habla Ami Vora en la entrevista. Sería interesante que Microsoft hiciera algo para Orcas pero parece que no será así o al menos no he leido nada sobre este tema.
Si habéis trabajado con WCF ¿ Qué os parece esta tecnología?¿Os parece sencilla?¿Estáis de acuerdo con las palabras de Ami Vora?
Cada vez en más sitios escucho lo bonito y maravilloso que es Scrum. Leo blogs, articulos, hablo con algunas personas que lo conocen y todos son cosas positivas.
Y sí, estoy de acuerdo en que Scrum es una buena metodología. Rodrigo Corral ya escribía hace tiempo sobre por qué le gustaba Scrum y estoy de acuerdo con él; es una metodología “sencilla”, fácil de entender, tiene normas claras, protege al equipo de desarrollo etc…
Pero en este post me gustaría alertar sobre el peligro de envaletonarnos y pensar que hacer una implantación de Scrum, o de cualquier otra metodología, es un proceso sencillo y que con poco esfuerzo cualquiera puede ponerse manos a la obra.
Uno no se levanta un día y dice: ¡HOY ME SIENTO AGIL! ¡VOY A USAR SCRUM!
Usar esta u otra metodología requiere realizar una serie de tareas y esfuerzos sin los cuáles no tendrá éxito.
Como primer tenemos que tener claro que ni Scrum ni cualquier otra metodología no es nada sin usar buenas prácticas. Si no se usan buenas prácticas olvidaros.
Los pilares de cualquiera metodología son las buenas prácticas y si éstas no se asientan correctamente será muy dificil usar Scrum; conocerlas, saber cómo se usan y sobre todo aplicarlas es la base del éxito. Esta afirmación puede parecer muy obvia y lógica pero muy pocas empresas que lo tienen tan claro. Pensad en los proyectos que hayáis realizado últimamente y revisad qué buenas prácticas empleais:
· ¿ Usáis una herramienta de control de fuentes?
· ¿ Usáis una herramienta de gestión de incidencias?
· ¿ Automatizais las builds?
· ¿ Hacéis unittets?¿ hacéis pruebas de humo?
· ¿Tenéis especificaciones? Por pequeñas que sean?
· …..
El test de Joel nos da una guía de que deberíamos emplear en nuestros proyectos antes de pensar en usar una u otra metodología.
Usar buenas prácticas es la base, pero tampoco pensemos que es lo único que hay que hacer. En el caso de Scrum es importante conocer y asumir las reglas de Scrum. No vale coger lo que nos interesa, un poquito y otro de allí. O sea hace Scrum o no se hace, pero no hay medias tintas.
Con este post no pretendo decir cómo se debe implantar Scrum, simplemente pretendo dejar claro que hacer Scrum o cualquier otra metodología no es una decisión trivial que se pueda tomar de un día para otro.
