September 2010 - Artículos
Leo en el blog de David Salgado una entrada acerca de pruebas unitarias que no tiene desperdicio, y leo aún con más interés si cabe los comentarios que dejan los lectores de su blog y de los que siempre se aprende algo.
Tentado me he visto desde el principio para escribir un comentario en su blog, de hecho, después de escribirlo y apunto de darle al botón de publicar he pensado que qué mejor sitio que mi propio blog para comentar algo con lo que me he "pegado" no una, sino mil veces, y que dada la extensión que puede tomar el tema, mejor abrir un nuevo hilo.
Paulovila hace unos comentarios acerca de si las pruebas unitarias no tienen sentido sino hay dinero para hacerlas, y no puedo estar más de acuerdo... con matices, matices que van a favor del comentario pero que ahora trataré de expresar de la mejor forma posible (espero que se me entienda perfectamente).
A niveles de coste, un proyecto debe ser iniciado solo si el coste del proyecto va a devolver un beneficio mayor que el propio coste, y siempre si ese beneficio está dentro de unos ratios marcados. El ROI o retorno de inversión es la mejor explicación para entender esto.
Para explicarlo de una forma más práctica, un proyecto debe ser iniciado si vamos a recuperar lo que hemos invertido y si tenemos claro que nos va a revertir un beneficio adicional al propio gasto, es decir, que no vamos a vender únicamente para cubrir los gastos porque entonces habremos perdido realmente tiempo con respecto a nuestra competencia y nuestra empresa no habrá crecido. Es lo que en castellano se diría la frase de comidos por servidos.
Dicho esto que es obvio, el problema fundamental de las empresas reside en lo que esas empresas contabilizan como gastos y partidas presupuestarias.
Evidentemente, y tampoco querría extenderme con muchísimo detalle, existen gastos directos y gastos indirectos. Los directos son muy claros y evidentes, mientras que los indirectos son más estimativos que los directos. Y no entro en valorar lo que se entiende por estimaciones porque daría para otra entrada mucho más larga que esta.
El caso es que muchas personas y empresas olvidan detallar gastos como por ejemplo la tinta y el papel de impresora, los bolígrafos, las libretas, los rotuladores para las pizarras, los cafés o incluso la luz por citar algunos pequeños ejemplos. Por eso muchas empresas deciden poner una partida presupuestaria de gastos generales.
Otro gasto son los sueldos del personal que va a trabajar en el proyecto, y ahí se prorratea siempre, ya que a lo mejor es necesario disponer de un Arquitecto de Software, pero ese Arquitecto estará en el proyecto durante un 7% del proyecto, por lo que los gastos a imputar se prorratean, y así hasta un largo etcétera que tampoco es cuestión de comentar ahora.
Tampoco trataríamos los gastos derivados de las licencias de Software y partida a través de su amortización. Y así podría seguir nombrando aspectos que muchas veces pasan desapercibidos... por lo menos en primera instancia.
Sin embargo, aún no he nombrado la base principal de esta entrada, de uno de esos "gastos", me refiero como no al gasto de las pruebas unitarias.
Aquí es donde quiero detenerme con más precisión para comentar algunas cosas que considero importantes y que cuando hablo con algunas personas veo que no quedan del todo claras.
Muchas empresas ven las pruebas unitarias como gasto que tendrían que salir de sus presupuestos. Algo que a todas luces es más que evidente.
El problema es que muchas empresas ven en ese gasto una pérdida y no una inversión. Ahí es donde se comienza a liar el asunto y donde debemos abrir bien los ojos.
Aquí podríamos definir que el gasto inicial de las pruebas unitarias y siempre y cuando las pruebas unitarias estén bien hechas (que no haya que repetirlas más de una vez porque están mal enfocadas o diseñadas), tendrá un retorno de inversión en modo de menos errores (nadie asegura que las pruebas unitarias resuelvan todos los males), mejor aspecto funcional, mejor experiencia y mayor satisfacción por parte del usuario, más seguridad y más convencimiento de que el Software hace lo que tiene que hacer, y por lo tanto, mayores posibilidades de que nuestro Software sea vendido a más usuarios o empresas que estarían satisfechos con la inversión (a modo de licencia) que han realizado por nuestro Software.
Evidentemente, cuanto mayor cualificado esté el equipo de desarrollo en
hacer esas pruebas unitarias, menor será el coste asociado a la
elaboración de esas pruebas unitarias, sin embargo, siempre habrá un
coste fijo asociado a la creación del propio conjunto de pruebas unitarias, y a medida que el proyecto avance, se irán cumplimentando y creando más pruebas unitarias. Porque otra cosa que no quiero tampoco discutir ahora, es que las pruebas unitarias deben hacerse al mismo tiempo que el desarrollo, porque sino luego, el coste para hacerlas es excesivamente elevado (no me acuerdo bien como estaba hecho, se me olvidan pasar pruebas que antes tenía claras, etc).
En todo esto siempre surge la misma pregunta: "¿para qué hacer pruebas unitarias?. Yo lo que quiero es tener mi Software ya hecho.".
A veces el tiempo apremia y muchas empresas están dispuestas a sacrificar parte de ese tiempo tan escaso a partes del desarrollo, y una de esas partes son las pruebas unitarias.
¿Con qué choca todo esto?. Con una sola cosa, la mentalidad de que las pruebas unitarias no revierten ningún beneficio ni afecta al ROI en nada más que los costes, cuando esto no es así.
Otra cosa es hacérselo ver a quienes tienen que tomar las decisiones, que ese es otro cantar.
En muy muy pocas empresas en las que he trabajado directa o indirectamente (y son unas cuantas), he podido ver a personas con las ideas claras sobre las pruebas unitarias. En un gran número de casos por no decir casi todos, las pruebas unitarias se entienden como gastos y sólo eso, gastos.
Siempre hago la misma pregunta. ¿Te comprarías un coche que nunca nadie lo ha probado?. Alguien diría, si no se ha probado yo no lo compraría,... pues bien, ese es el principio del ROI en cuanto a pruebas unitarias formuladas como gastos que retornan una inversión indirecta, porque si nadie ha probado nuestro Software... ¿con qué cara se lo instalamos a un cliente o lo vendemos?.
Indudablemente en esto hay una trampa manifiesta, y es que nadie nunca admite cual es la cantidad o calidad de esas pruebas unitarias y la cobertura de las mismas en su Software, y ya no hablemos de otros temas aparte de este hilo y que tienen que ver con las pruebas funcionales, etc.
Quizás en un futuro próximo se obligue al Software a llevar un sellito de "Probado", o como dicen algunas marcas "Testado", pero lo que está claro es que eso hoy por hoy no existe, y mucho menos mientras pensemos que las pruebas unitarias son evitables, que no ahorran tiempo y dinero en cuanto a mantenimiento del Software, que no aportan calidad al Software final o que son chorradas.
Lo único cierto es que nuestra cultura (al menos hablo de España) no está preparada para realizar pruebas unitarias al Software, y cambiar esa mentalidad cuesta más de una úlcera de estómago.
Finalmente y por asociarlo con las pruebas unitarias, nunca olvidaré una de las clases que recibí en la Universidad en la asignatura de marketing. Allí nos comentaban que es
difícil hacer un cliente, pero mantenerlo es más difícil, y perderlo
está chupado. Ahora bien un cliente perdido es casi imposible volverlo a
recuperar. ¿Alguien no se ha comprado "algo", le ha salido mal y no ha
querido volver a comprar esa misma marca nunca más y cada vez que le
pregunta alguien le cuenta su experiencia o dice... "esa marca ni de
coña"?.
Lo único cierto es que esto último que he puesto lo he podido constatar cada día, y aquí simplemente digo: que cada uno en su empresa haga lo que quiera, pero muchas veces no es lo que uno quiere sino lo que a uno le dejan hacer, y ahí es donde muchos desarrolladores nos mordemos las uñas hasta dejarnos los dedos casi pelados.
Yo lo tengo claro, las pruebas unitarias no son una elección y aportan calidad, pero ¿cómo cambiar el hábito y esta mentabilidad al menos a las empresas en España?. Si alguien tiene la fórmula de la coca-cola que la cuente por favor...
Hay una gran cantidad de programadores de Java que están cada vez más interesados en la plataforma .NET.
Sin embargo, muchos de ellos son reticentes al cambio, otros sin embargo están más abiertos al cambio sabedores entre otras cosas, que C# es casi igual a Java en cuanto a nomenclatura, por lo que la curva de adaptación es más pequeña de lo que sería el cambio a VB u otros lenguajes de desarrollo.
Sin embargo, no muchos han oído hablar de IKVM.NET, o lo que es lo mismo, la implementación de Java en Mono y .NET Framework.
IKVM es un proyecto de código abierto que tiene como objetivos principales la implementación en .NET de la máquina virtual de Java, la implementación en .NET de las clases de Java, y un conjunto de herramientas que permitan la interoperabilidad entre Java y .NET.
Esto puede llegar a ser realmente útil en el caso de querer por ejemplo convertir jars a .NET o de querer ejecutar dinámicamente clases java. Todo con la cautela que esto implica.
Pero lo llamativo realmente para los programadores de Java que quieren pasar a .NET y no se atreven a dar el salto definitivo, es que estas librerías les facilitarán definitivamente ese salto.
Si quieres saber más acerca de IKVM, haz clic en este enlace.
Si quieres descargar la última versión de IKVM, haz clic en este otro enlace.
Si quieres estar informado a la última del avance de IKVM, haz clic en el enlace del blog de IKVM.
Todos sabemos o deberíamos saber a estas alturas que escribir código es una tarea de creatividad, y que cada desarrollo es diferente de cualquier otro que hayamos hecho previamente.
Existen patrones de coincidencia y parecidos razonables, pero nunca un proyecto es y será igual a otro.
Sin embargo, he tenido la fortuna de trabajar en varias empresas y en prácticamente todas me he encontrado el mismo problema o patrón de comportamiento que daría a una entrada más extensa que esta.
La dirección quiere desarrollar ideas, procesos, aplicaciones, utilidades,... de forma ágil y rápida. Ok hasta aquí, pero el problema principal reside en lo que se entiende por rápido y ágil.
Muchas empresas entienden por rápido y ágil que el mero hecho de escribir código es algo trivial, repetitivo y sin mucho más fundamento. Es decir, el programador es lo más parecido a una máquina.
Esto me recuerda indudablemente a una entrada de Rodrigo Corral que escribió ya hace algún tiempo en su blog.
Admito que yo mismo me he hecho mis propios Frameworks y herramientas que me permitan ahorrar tiempo y me genere automáticamente algunas porciones o partes de código que siempre empleo en todos los proyectos, pero no todo, más que nada porque dada la particularidad de cada proyecto, hacerlo de forma general es completamente imposible (al menos de momento).
El caso es que ante esto y Dios mediante... porque sino me temo que los informáticos tendremos los días contados, tenemos que tener en cuenta diferentes factores y aspectos al codificar y ser creativos. Factores que nos faciliten la codificación para interpretarla adecuadamente.
Así, cuando escribimos código se recomienda ser organizados y ordenados.
El código no es para quién lo escribe, sino para quién lo lee.
Si eres programador y tienes la suerte de que tu código lo vas a leer y mantener sólo y siempre tú, felicidades, pero en el 99,99% de las empresas y organizaciones esto no suele ser así.
Ante esto, siempre que un programador hace frente a una porción de código de otro programador, incluso y aunque sea su mejor amigo, tenderá a pensar que él lo hubiera hecho mejor porque si de algo presumimos los programadores es de pensar siempre que nosotros mismos lo hacemos mejor que otro programador. Créeme que hay pocos que se libren de este pensamiento.
Por esa razón y tratando de minimizar todos estos aspectos, y entre ellos el de creerse mejor que otro, muchas empresas que comienzan un desarrollo desde cero lo primero que hacen es crearse una serie de documentos, guías o patrones que deberán ser utilizados a lo largo de todo el proyecto.
Estos documentos no tratan de fastidiar al programador haciéndole perder el tiempo leyendo una guía de buenas prácticas, sino simplemente de crear una línea de trabajo homogénea a todo el equipo que permita a todo el mundo hablar prácticamente el mismo dialecto o idioma.
Si seguimos estas pautas, estaremos dotando al código de "cierta" calidad en cuanto a su comprensión lectora y su posterior mantenimiento.
Otra cosa y capítulo aparte serían las pruebas unitarias y las pruebas funcionales, pero esto es otro tema que prefiero no mentar ahora mismo para no desviarme demasiado.
El caso es que cuando nos sentamos frente a la pantalla del ordenador y arrancamos Visual Studio para empezar a codificar, debemos tener muy claras estas pautas, y cualquier ayuda es bienvenida.
Por esa razón, en primer lugar he querido hacer unos pequeños comentarios que nos hagan meditar, reflexionar y pensar en qué punto estamos cada uno y si estamos organizando nuestro código de forma correcta o no, y en segundo lugar, apoyarnos en el entorno de desarrollo para que nos ayude a ser un poco más organizados.
De hecho, una de las características ocultas de Visual Studio es la posibilidad de crear líneas verticales de puntos en el editor del entorno, más conocidas como Column Guides.
Estas líneas nos ayudarán a mantener una guía de codificación muy concreta que deberemos crearnos previamente y que nos permita escribir el código de forma ordenada.
Pero lo mejor es siempre ir a los hechos y dejarnos de palabrerías.
Empezaremos por Visual Studio 2008.
¿Cómo son las Column Guides en Visual Studio 2008?
Lo mejor es ver una imagen.
Observando la imagen vemos que el entorno muestra unas líneas verticales que nos ayudan a escribir nuestro código dentro de un patrón, como aquellos cuadernillos que teníamos cuando empezábamos a estudiar con unas guías en su margen izquierdo y/o derecho que nos servían para no salirnos de ellos.
¿Y cómo habilitar las Column Guides?
De una forma muy sencilla.
Abriremos el registro de Windows y buscaremos la entrada: HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\9.0\Text Editor.
Dentro de esa entrada agregaremos una nueva cadena de nombre Guides y de valor RGB(225, 0, 0), 4, 8, 80.
La lectura de este valor es muy sencilla.
Se crearán líneas verticales de color rojo (255,0,0) en la columna 4, 8 y 80.
La columna 80 es empleada de forma estándar. De hecho, Microsoft la usa internamente. Evidentemente, nosotros seguiremos siempre las directrices de los documentos y guías de codificación que hayamos preparado para nuestra empresa, compañía o proyecto concreto.
El resultado de este uso es el que veíamos en la primera imagen con el entorno de Visual Studio 2008 de fondo.
Ahora bien, ¿es válido este truco para otras versiones de Visual Studio?.
La respuesta es sí para todas las anteriores a Visual Studio 2010. La excepción es Visual Studio 2010.
Con Visual Studio 2010 Microsoft ha apartado esta característica del entorno, sin embargo, podemos llevar a cabo esta acción utilizando las Productivity Power Tools, que por otro lado recomiendo instalar.
Si quieres obtener las Productivity Power Tools para Visual Studio 2010, haz clic en este enlace.
Una de las herramientas de este paquete gratuito es el Editor Guidelines que puede ser instalado aparte.
Aún y así, con el mero hecho de descargarse este paquete no vale para tener las líneas verticales dentro de nuestro entorno.
Deberemos ir al registro de Windows y hacer las oportunas modificaciones, exactamente igual que con Visual Studio 2008 o versiones anteriores.
La diferencia con respecto al ejemplo anterior es que en este caso abriremos el registro de Windows y buscaremos la entrada: HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\10.0\Text
Editor.
El resultado dentro de Visual Studio 2010 es el que se puede ver en esta otra captura de pantalla:
Sin embargo, en el caso de Visual Studio 2010 y desde el mismo IDE, los menos frikis pueden hacer clic con el botón derecho del ratón y acceder a una opción del menú emergente que nos permitirá agregar y eliminar guidelines y modificar su color.
Espero que esta información te parezca útil.
Si quieres desarrollar aplicaciones de Silverlight 4 con Visual Studio 2010, sabrás que para ello deberás instalar las Microsoft Silverlight 4 Tools para Visual Studio 2010.
Estas herramientas las podrás encontrar en este enlace (aproximadamente 36 Mb).
Obviamente, se aconseja seguir los pasos de instalación que se indican en el enlace de descarga.
Lo que tenemos claro es que el paquete de instalación instalará los siguientes componentes:
* Silverlight 4 Developer Runtime
* Kit de desarrollo de software (SDK) de Silverlight 4
* Actualización para Visual Studio 2010 y Visual Web Developer Express 2010 (KB982218)
* Silverlight 4 Tools para Visual Studio 2010
* WCF RIA Services V1.0 for Silverlight 4
* F# Runtime para Silverlight 4
Sin embargo, el paqiete de instalación podrá devolver un error (o no) al instalar Silverlight 4 Developer Runtime.
Y es precisamente este paso de la instalación el que cuando desarrollamos un proyecto de Silverlight 4 con Visual Studio 2010, hará que Visual Studio 2010 nos devuelva un error al depurar nuestro proyecto.
El error hace que el depurador se detenga y nos sea imposible probar nuestro desarrollo.
¿Cómo resolver este problema?.
La solución es extremadamente sencilla.
Bastará con acudir al siguiente enlace de Microsoft y descargar e instalar Silverlight Developer por separado. El paquete de instalación apenas ocupa 8 Mb.
Espero que este detalle le resuelva la vida a más de uno.
Microsoft ha publicado una nueva versión de su herramienta gratuita ILMerge. Se trata concretamente de la versión 2.10.0526.
La descarga ocupa unos 665 Kb y puede ser realizada desde este enlace.
Recordemos que esta utilidad permite mezclar varios ensamblados separados en un único ensamblado.
Esos ensamblados pueden ser ejecutables o librerías dll.
La herramienta se ejecuta bajo el paragüas de .NET Framework 2.0 y permite incluso combinar varios pdb en un único fichero pdb.
Aunque también es capaz de mezclar ensamblados de la versión 1.0 y 1.1, no es capaz en este caso de mezclar o combinar varios pdb en uno sólo.
Por si alguno aún no se ha enterado aún, hace un mes y medio Microsoft sacó a la luz una nueva plantilla de Scrum TFS 2010.
Esta plantilla gratuita puede ser descargada desde la galería de Microsoft para Visual Studio 2010 en este enlace.
No obstante, si quieres curiosear las opciones de la plantilla antes de instalarla, te recomiendo entonces otro enlace sobre la guía de Visual Studio Scrum 1.0.
Se trata de un enlace que contiene un archivo zip, que una vez descomprimido, te mostrará en ficheros html todas y cada una de las opciones de esta plantilla, lo cuál te ayudará a buen seguro para determinar si instalas la plantilla en TFS o no.
Podrás acceder a esta documentación en este enlace.
Por si no lo sabes o por si no te has enterado, Google España ha creado su 1er Desafío Google Chrome 2010.
El desafío tiene como objetivo poner a prueba la habilidad y originalidad a la hora de desarrollar extensiones para Google Chrome.
Se trata de que el desarrollador o desarrolladores (máximo 2), desarrollen extensiones para Google Chrome antes del 15 de Octubre (la competición empezó el pasado 1 de Septiembre).
¿El premio?. Un móvil Nexus One para los ganadores, premios que serán notificados el 22 de Octubre de este año.
No obstante y antes de que más de uno se anime a participar, una cuantas cosas importantes.
Lo primero de todo leer y entender los requisitos y normas del concurso. Posteriormente y según esas normas, revisar la galería de Google Chrome para ver que no exista ninguna extensión igual ya publicada (en español u otro idioma), rellenar el formulario de participación y residir en España, además de seguir el resto de normas que se indican. Quizás la más complicada sea la creatividad, pero ahí reside el quiz del concurso.
Sin embargo, si eres de lo que como yo no sabes mucho sobre las extensiones de Google Chrome entonces estás de suerte, sobre todo si vives o pasas por Madrid, ya que el próximo Jueves 9 de Septiembre a las 19:00 horas Google organizará un workshop gratuito sobre este tema.
A continuación te indico los enlaces más destacables de este desafío:
- Noticia oficial del blog de Google España sobre el desafío Google Chrome 2010.
- Página web oficial sobre los detalles y normas del desafío Google Chrome 2010.
- Extensiones de Google Chrome.
- Formulario de participación en el desafío Google Chrome 2010.
Asi que si te animas a participar... ¡¡¡mucha suerte!!!
Ya está aquí, ya ha llegado, ese Samsung Galaxy Tab tan esperado..., aunque a más de uno le habrá decepcionado en parte.
Este dispositivo es uno más en el camino de las tablet que comenté en Enero iba a entretenernos y mucho durante este año 2010 y el que viene. El cotarro se está animando y eso nos viene estupendamente a los usuarios, ya que el resto de fabricantes se pondrán las pilas a buen seguro.
Lo cierto es que era un secreto a voces que ayer Samsung iba a lanzar su modelo Galaxy, la misma Samsung que hace poco sacó lo que se ha pasado a denominar como el mejor móvil de la empresa, el modelo Tab, al igual que Apple hizo con su iPhone sacando su móvil y su tableta. Creo que está claro que Samsung ha nacido para tratar de hacerle la puñeta a Apple si se me permite la expresión.
Pues nada, dicho y hecho, Samsung ha sacado a la luz su modelo dotado entre otras cosas de GPS, video Full HD (según comentan ellos a pesar de su pantalla de 7"), multi-touch, batería de 7 horas de duración (pelín por detrás de las 10 horas de Apple), reproductor multimedia, capacidad de leer revistas, periódicos y libros,WiFi, GPRS, soporte para Flash, cámara de 3 Mp autofocus con flash,...
Vamos, una gran cantidad de características que deben hacer temblar a Apple porque a falta de comparativas tiene pinta de ganarle bastante la partida incluyendo su pantalla que dicen que está a la altura en calidad o mejora la de Apple. Sin embargo... siempre hay "peros". Nadie es perfecto y es una opinión personal.
Me sorprende a medias que Samsung haya apostado por Android 2.2 (Froyo), digo a medias porque los rumores apuntan a que el Samsung Galaxy Tab podrá ser actualizado a Android 3.0 (Gingerbread) en cuanto salga, algo que está esperando mucha gente debido a los rumores sobre lo que muchos dicen será una revolución de Android. El caso es que Samsung ha decidido salir con esta apuesta a pesar de que Android 3.0 está a la vuelta de la esquina, supongo que esa apuesta es para no dejar más tiempo a Apple con la ventaja que ha sacado saliendo en primer lugar pese a la gran cantidad de críticas que por otra parte y con razón ha recibido.
No obstante, según indican otros medios en Internet, a Samsung se le fue la lengua ayer al dejar caer en la parte de preguntas y respuestas del evento que Samsung prepararía una tableta más larga (presumiblemente la sí esperada Samsung Galaxy Tab de 10") con un sistema operativo Android 3.5 (Honeycomb).
¿Acaso es que Google está preparando un Android 3.0 para los pobres mortales mientras los fabricantes ya están trabajando con la 3.5?. Me resultaría bastante normal ya que como todos sabemos, Google saca sus avances con cuentagotas y a quien quiere trasladárselos realmente. El resto vamos a rebufo siempre.
El caso es que en la red se indica que Android 3.0 aparecerá el próximo mes de Octubre, y muchos fabricantes lo estarían esperando como agua de Mayo, ya que de 1024x600 píxeles que soporta como máximo Android 2.2 (según parece) pasaríamos a 1280x760 píxeles que soportaría Android 3.0, por lo que el soporte de las pantallas de 10" sería una realidad práctica y empezarían a aparecer este tipo de dispositivos. Muy posiblemente, Samsung al igual que el resto de fabricantes están esperando a este acontecimiento, por lo que el final de año respecto a los tablet dotados con Android puede ser más entretenido de lo normal, sobre todo cuando nos acerquemos a las Navidades.
Al acecho por su parte está la propia Google preparando su tablet, los fabricantes que apostarán por Microsoft y HP con su webOS,... todo esto mientras Steve Jobs se sienta en su banqueta, observa y medita sobre su Tablet v2.0.
Nada nada, de momento nos pondremos a preparar unas palomitas y a mirar el espectáculo con Steve Jobs, esperar un poquito a que aparezcan todas las novedades y tendencias y terminar de decidirnos si nos vamos con Microsoft, webOS, Apple, Froyo, Gingerbread, Honeycomb, o simplemente seguimos tan felices con lo que tenemos (que no está nada mal). Tiempo al tiempo, pero cada vez me seducen más estos cacharritos y hoy por hoy estoy más animado a hacerme con uno que a quedarme sin él. No sé si le daré mucho uso o no sabiendo que me tiro programando casi todo el día, pero algún uso seguro que le doy. :-)
Accedereis a la web oficial del producto en este enlace.
P.D.: creo que en España saldrá exclusivamente con Vodafone.
DevExpress ha lanzado hace pocas fechas CodeRush Express v10.1.6.
Lo más destacable es que esta herramienta de refactorización, navegación y declaración es que está disponible gratuitamente para desarrolladores que trabajen con Visual Studio 2010 a excepción de los desarrolladores que dispongan de Visual Studio 2010 Express Edition.
Esta herramienta está disponible tanto para desarrollos con C# como para desarrollos con VB.
Video en inglés en el que nos explican en casi 22 minutos las novedades y características de CodeRush Express v9.1.
Accederás a la página de descarga en este enlace de Microsoft o directamente en la página web de DevExpress.
Microsoft ha anunciado ayer por la tarde el lanzamiento de Windows Phone 7 RTM tal y como se puede leer en el blog del equipo de Windows Phone.
Cabe destacar que las Windows Phone 7 Developer Tools harán aparición el próximo 16 de Septiembre tal y como comenté en mi blog hace algunos días.
Sigo pensando en que Microsoft se tiene que poner las pilas y que ha llegado algo tarde a la carrera.
El iPhone y sobre todo Android (que sacará dentro de poco su versión 3.0) le está ganando la partida, y de hecho, muchos fabricantes que iban a lanzar sus tablet con sistemas operativos Microsoft les están dando la espalda ahora y abogan por hacerlo con Android (¿habrá pasta de por medio para ese cambio radical?).
El caso es que (y hablando de tablets) los fabricantes de tablets igual ahora que ha aparecido por fin la versión RTM se lo piensan más y terminan situándose tanto en el sistema operativo de Microsoft como en el de Google y sacan tablets en los dos sistemas operativos. Por otro lado, en los últimos meses Microsoft ha dado coletazos propios de un conductor ebrio, indicando que Courier estaba muerto y poco después y viendo la "castaña" del iPad de Apple que estaban creando un tablet nuevo y propio, tal y como ha hecho Apple y tal y como está haciendo Google.
Windows Phone 7 llega para competir con iPhone y Android. Antes de iPhone y Android, Microsoft compitió sobre todo con Palm (ahora propiedad de HP que sacará su webOS o sistema actualizado montándolo en sus tablet que aparecerán en los próximos meses).
Como podemos ver, la guerra de los tablet y los móviles está más candente que nunca, e incluso Google se ha puesto a ofrecer servicios de telefonía con llamadas a precios ridículos,... pero que tenga cuidado Google porque está andando en terreno pantanoso y las operadoras de telecomunicaciones no están muy contentas con las hazañas de la empresa más "moderna y chic de la galaxia", tanto es así, que si Google continúa con sus ambiciosos planes, es prácticamente seguro que las operadores de telecomunicaciones terminarán demandando a la empresa.
Pero sea como sea, la noticia es Windows Phone 7 y que ya está (por fin) en versión RTM. Más vale tarde que nunca.
Según el equipo de desarrollo de Windows Phone 7, es una versión madura y probada.
Ahora sólo espero poder tener uno entre mis manos, jubilar mi Windows Mobile 6.5, continuar con mi Android, desarrollar aplicaciones para Windows Phone 7 y compararlo con el Android también para ver hasta donde llega. De momento, sólo puedo hablar de teoría cuando nombro Windows Phone 7, pero espero poder hablar más a nivel práctico cuando me enfrente a un terminal que lo tenga instalado.
Finalmente, apuntaré que un compañero de trabajo me ha comentado que leyó en un sitio en Internet que hicieron pruebas con iPhone, un Android y un Windows Phone 7 (sería en versión RC digo yo), y el Windows Phone 7 ganaba a todos en cuando a velocidad de inicio. El caso es que a partir de ahora aparecerán webs e informaciones que nos permitan comparar los diferentes "bichos" y así decidirnos.
De cara al desarrollo, esperaremos al 16 de Septiembre para empezar a crear nuestros "engendros" Software.
¡A disfrutarlo!