Los 17 consejos definitivos que todo desarrollador debería seguir para triunfar en el mundo del software | Variable not found

Te digo una cosa, no mezcles el alcohol y las drogas, no son buenas y menos si mezclas...

Como fracasar con éxito

Recuerdo que llevábamos varios meses encerrados en una de las habitaciones donde vivía con un par de amigos, con la intención de desarrollar software de gestión, apoyados por una pequeña empresa que quería comercializar el producto, ninguno de nosotros cobraba sueldo alguno y manteníamos un estricto horario, similar al de cualquier otro empresa, teníamos el sueño de que algún día podríamos ganar lo suficiente como para establecer una empresa que nos permitiera vivir cómodamente, el trabajo se hacía cada día más duro, pues además de no contar con ningún incentivo a final de cada mes, debía asumir algunos gastos derivados de nuestro trabajo, pago del teléfono, gasolina, luz y diversos gastos que se originaban por realizar la actividad. La empresa interesada en el producto, nos surtía de material y un poco de equipamiento, algún router para la red, material ofimático y otras cosas. Al cabo de casi un año de trabajo, uno de los compañeros se fue a realizar el servicio militar y nos quedamos solo dos, encontramos la posibilidad de alquilar un local, para nosotros era prácticamente impensable, ya que no disponíamos de ningún ingreso, pero el alquiler era muy bajo y buscábamos la independencia de un lugar para trabajar más concentrados en nuestro trabajo, el local era simplemente una habitación sin ventanas de unos 12 metros cuadrados ubicado en la parte baja de un edificio, decidimos arriesgarnos y sacar la licencia fiscal para poder vender software y equipamiento informático, pensamos que con que lográsemos vender dos o tres equipos al mes y algún programa podríamos pagar el alquiler y tendríamos lo suficiente como para poder continuar con lo que verdaderamente nos gustaba, desarrollar software, fue curioso como primero a través de un amigo nos compraron un equipo, luego otro y otro y en poco tiempo las ventas fueron incrementándose, aunque seguíamos sin un nivel de beneficios aceptable, ni siquiera sacábamos lo suficiente para asumir un sueldo. Aun con estos problemas y debido a la ilusión que teníamos por nuestra empresa, decidimos arriesgarnos y alquilar un local más grande de cara al público, solicitamos un préstamo avalados por nuestros padres y comenzamos nuestra primera aventura empresarial.
Lógicamente nuestros gastos se dispararon, tuvimos que contratar a alguien que estuviera permanentemente en la oficina y los diversos impuestos y gastos derivados de la actividad, acondicionamiento del local, luz, teléfono, etc., así que empezamos a salir a la calle en busca de empresas que nos permitiesen aumentar nuestros ingresos, el camino fue muy duro, establecer una simple entrevista era muy complicado ya que normalmente preferían empresas conocidas o consultoras con mayor experiencia, la mayor parte de los empresarios no veían valor añadido al desarrollo de software, preferían un paquete estándar en el que el coste fuese más pequeño y habitualmente descartaban cualquier tipo de desarrollo que pudiera aportarles mayor valor añadido. Por el medio intentamos un poco de todo, desde dar cursos de formación a empresas a cualquier colectivo hasta llegar a acuerdos comerciales con otras empresas del sector y colaborar en el desarrollo de sus aplicaciones.
Los clientes entraban en la tienda con el fin de informarse sobre los costes de un ordenador personal y demandaban al mismo tiempo que les instalásemos todo el software necesario, (sistema operativo, paquete de ofimática, antivirus, etc.), por supuesto totalmente gratis, yo me indignaba con esto, pues la mayor parte reusaban a realizar la compra en nuestra empresa debido a que otras les ofrecían estos servicios de “valor añadido”.
Recuerdo que yo entonces era un “soñador”, soñaba con tener una empresa, con trabajar duramente y en pocos años aspiraba a vivir cómodamente, cuando me hablaban de dinero yo les respondía que para mí no era importante, que el dinero era lo de menos, el dinero ya vendría, después del trabajo, nunca me preocupo especialmente. Después de un tiempo me di cuenta de que la empresa había tomado un camino muy distinto del que tenia planeado, nos habíamos convertido en una empresa de informática habitual, y habíamos dejado de lado el desarrollo de software, lo único que podría diferenciarnos y aportarnos valor. Finalmente después de un tiempo abandone la empresa.
Este fracaso, me permitió más adelante, reflexionar sobre los errores que cometí.
Cuando conformamos la empresa no teníamos una idea clara del negocio, teníamos una idea general pero no contábamos con un proyecto claro, ni siquiera con un pequeño estudio de mercado, nos lanzamos con un desconocimiento total, carecíamos de un plan estratégico, no teníamos un sector determinado al que atacar, ni una idea clara que seguir, tan solo hacer lo que fuera para subsistir y luego dependiendo de la situación que alcanzásemos tomaríamos posteriores decisiones.
Queríamos desarrollar software de gestión y más adelante aprovecharlo para realizar algún vertical. Algo que ya existía en el mercado y que aunque no era tan completo como el nuestro, cumplía con los objetivos básicos y además era mucho más barato.
Destinamos la mayor parte de los recursos a desarrollar el software y posteriormente intentamos comercializarlo. Este fue uno de los mayores errores, realizamos un producto, sin analizar el mercado ni a la competencia, sin recursos económicos, sin un sponsor, asumiendo que como nuestro software sería mucho más completo que los demás y se vendería sin problemas. Es decir, primero producimos el producto y posteriormente intentamos comercializarlo. Posteriormente y debido a este fracaso, deducí que debía invertir el orden “vender y luego producir”, curiosamente al cabo de unos años y estudiar el sistema LEAN que se basa en una idea similar, fabricar en base a la demanda… es decir ‘vender antes de producir’.
No teníamos un plan comercial viable. Contar con un estudio de mercado, para atacar a sectores en los que la competencia no estuviera presente hubiera sido mucho más inteligente que intentar competir con un producto que ya existía en el mercado contra empresas solventes, mucho mejor posicionadas que nosotros en un mercado que dominaban desde hacía algunos años.
El desconocimiento del mercado hizo que cuando terminamos el desarrollo, nos encontramos con que la mayor de nuestro posibles clientes, se había decantado ya, por otros productos más sencillos y baratos, la competencia había hecho todo lo contrario, desarrollo un producto sencillo que no requiriese mucho tiempo y lo puso en el mercado un precio mucho menor, de esa manera comenzaba a retornar parte de la inversión y poco a poco iban aumentando la funcionalidad, además sus clientes se convertirían en usuarios potenciales de sus versiones más avanzadas que habitualmente tenían precios mucho más elevados. Esto les aporto feedback para mejorar sus versiones, ‘me acuerdo de Scrum con las entregas continuas de software…’, la penetración era mucho más rápida porque al cliente no le importaba desembolsar un poco de dinero por el software y posteriormente según sus necesidades podría ampliar a versiones más avanzadas, todo esto hizo que en poco tiempo nuestro producto fuese mucho menos competitivo.
Los programas que realizaba la competencia, cubrían tan solo aspectos los aspectos básicos que la gente necesitaba, la mayor parte de los clientes empezaba a trabajar con computadoras personales con lo que un programa muy complejo hubiera fracasado, nos ocurría a menudo que cuando alguien veía nuestro programa comentaba, ‘es excelente, pero tiene demasiadas opciones…’, a mi no me hacen falta tantas, nunca modificare un informe, no sé si podre manejarlo. Resulto que nuestro mercado no estaba preparado para un producto tan complejo. Nos olvidamos de estudiar los requerimientos de los clientes, en lugar de esto, intentamos hacer un programa que cubriese todas las necesidades existentes, esto hizo que nuestro producto fuese mucho más complejo de entender y manejar, además el desarrollo duro más de dos años, en este tiempo la competencia se hizo con un mercado potencial de clientes inmenso.
Como necesitábamos dinero para mantener la empresa y no logramos que el software desarrollado se vendiese como queríamos, intentamos buscar una empresa que estuviera interesada en comercializar el producto, viajamos a Madrid y se lo ofrecimos a varias, la mayoría reusaba, pues ya contaban con algún producto que si ser tan completo, conocían perfectamente y les resultaba fácil adaptarlo a las necesidades de sus clientes, aunque hubo un par de ofertas serias de compra que pasaban por hacerse con todo el código fuente y controlarlo completamente, de bastante dinero, pero no quisimos renunciar a su control, así que lo descartamos. Si hubiéramos vendido el producto, el dinero nos hubiera permitido continuar desarrollando la empresa durante unos años cómodamente y podíamos haber dedicado otros recursos a realizar otros productos, pero no queríamos desprendernos de un programa que considerábamos como uno de los mejores del mercado y éramos demasiado ambiciosos, queríamos hacer mucho en muy poco tiempo.
A partir de aquí, para subsistir nos dedicamos a vender hardware, dar soporte y mantenimiento a empresas, formación, instalación de redes, etc., en fin todos aquellos servicios que dan las empresas de informática, pero en esto, no aportábamos ningún factor diferenciador importante.
Estoy convencido de que si hubiéramos dedicado un poco de tiempo a estudiar y analizar en detalle el mercado, podríamos haber llegado a tener una idea clara de negocio, posteriormente lo pude ver claro con empresas que triunfaron porque orientaron sus desarrollos a hacer programas de gestión a Concesionarios, Hoteles, Abogados, Dentistas y otros, sectores que no disponían de ninguna solución de software.
Además de esto, nuestra inexperiencia hizo que en varias ocasiones, aceptásemos proyectos en los que posteriormente descubrimos que los clientes eran auténticos profesionales del engaño, aceptaban el presupuesto sin pestañear pero a la hora de cobrar, descubríamos que muchos nos engañaban, recuerdo que hubo un proyecto en el que después de finalizarlo nos enteramos que el cliente estaba en la ruina y que debía dinero a mucha gente realizando prácticas similares, no creáis que fue solo un caso, sufrimos varios, alguno de ellos de importantes sumas de dinero que nos complicaron mucho la vida. La importancia de realizar un estudio del cliente es fundamental, cobrar a la firma de un contrato un porcentaje del proyecto y asegurarnos de la solvencia del cliente son aspectos muy importantes que se deben realizar antes de aceptar cualquier proyecto, existen empresas como Crédito y Caución que aseguran el pago de un determinado porcentaje de la cantidad facturada a cambio de un porcentaje de la operación.
No logramos convencer a las empresas de que nuestros servicios ofrecían valor añadido, les ofrecíamos lo mismo que las demás, algo que los demás hacían igual que nosotros. Y porque una empresa va a confiar en alguien que no conoce y que además no ofrece nada nuevo…, estaba claro que nuestro objetivo inicial había variado, ahora ya no desarrollábamos software, tan solo hacíamos lo que fuera para subsistir, y nos olvidamos del verdadero objetivo de nuestra empresa.
No supimos analizar bien nuestros costes, cuando comenzamos la actividad nos dimos cuenta de todo lo que debíamos asumir, pago de autónomos, seguridad social, IAE, gastos de luz, agua, teléfono, nóminas, seguros sociales, mobiliario, acondicionamiento del local, declaración de IVA, seguro del local, asesoría contable, alarma, gastos por líneas de crédito y transacciones bancarias, recuerdo que pusimos un aparato para pagar con tarjeta, nos enteramos que VISA llega a cobrar un 4 % por cada transacción que realicen los clientes, recuerdo que algunos productos informáticos apenas tenían marguen comercial. Os aseguro que por pequeño que sea el negocio, la lista de gastos es interminable, y claro podéis esperar ‘sentados’ que los Ayuntamientos y otros Organismos Oficiales os ayuden, lo único que les interesa es ampliar sus ingresos. Así que debéis tener claro todos los gastos antes de comenzar vuestra actividad.
No contábamos con una estrategia comercial seria, no podíamos permitirnos un agente comercial especializado, vender software o servicios informáticos requiere profundos conocimientos técnicos y comerciales, encontrar un comercial en este sector es muy complicado, al carecer de medios hizo que tuviésemos que dedicarnos a realizar esta labor, carecíamos de la suficiente experiencia, el desconocimiento del perfil de los empresarios de la zona, que no creían como yo, en el valor que podría aportarles el software a medida, hizo que la mayor parte de los empresarios reusasen a aceptar nuestros servicios y que seguramente un comercial con experiencia podría haber triunfado donde yo fracase.
No contábamos con un sponsor que financiase nuestro proyecto y desde luego no teníamos medios económicos, con lo que solamente subsistir mes a mes ya era un logro para nosotros, pero siempre nos obligaba a estar en la cuerda floja, si un mes no realizábamos el objetivo de ventas, la empresa se tambaleaba y varias fueron las veces que estuvimos a punto de cerrar, dedicábamos todas nuestras energías a llegar a fin de mes.
No dedicábamos tiempo a innovar, a poner en la mesa ideas diferentes y realizar algo que nos distinguiese de nuestros competidores. Esto hizo que nos incorporásemos a un mercado en el que nuestros competidores tenían mucha ventaja, disponían de mayor experiencia y habitualmente contaban ya con una cartera de clientes. La mayoría no tenían que preocuparse por subsistir, con lo que podían contar con más recursos y ser más competitivos.
Debido al poco tiempo que teníamos, empezamos a dejar de formarnos, tan solo dedicábamos un poco de tiempo cuando podíamos, así que con el tiempo fuimos perdiendo valor en nuestro mercado, pero nuestro trabajo no daba para más, así que pasamos de ser desarrolladores a ‘empresarios de poca monta…’
Los problemas económicos, administrativos y comerciales fueron aumentando y hacían que dedicásemos prácticamente todos nuestros recursos a subsistir y apenas teníamos tiempo para pensar, no nos paramos a ver cómo mejorar, como hacer cosas que nos aportasen valor, nos movíamos por impulsos, a petición de la demanda de algunos clientes que tan solo nos permitían subsistir y con el único objetivo de llegar a fin de mes. Nos fue prácticamente contratar personal adicional, desde técnicos especializados hasta comerciales con conocimientos del entorno, esto hacia que tuviésemos que hacer de todo, desde barrer hasta encargarnos de realizar presupuestos de equipos, con lo que fuimos dejando en otro plano aquello que nos podría diferenciar de los demás y nos permitiría llegar a ser más competitivos.
No logramos convencer a otras empresas del sector de que la colaboración podía hacer que estableciendo ciertas reglas de compromiso, nuestros márgenes comerciales mejorasen y ofreciesen mayor valor añadido. La incapacidad para llegar a acuerdos con nuestros competidores hizo que tuviésemos que renunciar a la mayoría de la venta de software y esto elimino un mercado que podría habernos ayudado en nuestros objetivos.
La parte positiva, es que al final, este y otros fracasos, me ayudaron a lo largo de toda mi trayectoria profesional a entender mejor cómo se comportan los mercados, la importancia del cliente y la competencia, de la colaboración, del trabajo en equipo, de la innovación, que de otra forma, difícilmente hubiera podido aprender. He tenido el privilegio de poder “intentarlo”, algo que muchas personas ni siquiera se han atrevido o que su condición no se lo permitirá a lo largo de su vida, he aprendido mucho de las personas que nos rodean y que los errores, nos enseñan aspectos que de otra forma, serian muy difíciles de aprender, por eso pienso que aquel que ha fracasado, tiene mucho más valor que él no lo ha hecho nunca, los errores del pasado, nos enseñan cómo mejorar nuestro futuro y a no cometer los mismos errores, de ahí la importancia del conocimiento de la historia.
He aprendido que en la colaboración y el valor de las personas está la clave de todo, en que pensar antes de hacer las cosas es mucho más importante que hacerlas y luego pensar…, aunque a veces haya que arriesgarse, que el trabajo en equipo, la formación continua, la innovación y por supuestos ‘los fracasos’ son aspectos que conducen al éxito.
Este es un sector proclive al cambio y la innovación y tenemos un mercado inmenso esperando a ser explotado, así que animaros no tengáis miedo al fracaso, pero cuidado, no os engañéis, nadie os va a regalar nada, el dinero es el primer objetivo de una empresa, que una empresa tenga éxito pasa solo por una cosa, ganar dinero, si la empresa no gana dinero no podrá alcanzar sus objetivos, para poder establecer una empresa debemos tener un plan establecido que asegure la viabilidad de esta, desde el principio, sobre todo al inicio que es cuando más falta nos va a hacer.
Mis fracasos me han enseñado mucho, si tuviera que poner en marcha una nueva empresa de desarrollo de software, desde luego haría cosas muy diferentes, algunas de ellas serian:
Buscar una idea y desarrollarla, intentar que esta sea innovadora o que aporte algo que marque la diferencia frente a vuestros competidores, establecer una línea de negocio clara realizando un plan estratégico con su análisis de costes y beneficios, estudiar las  ventajas e inconvenientes, analizar cómo, después de un tiempo podéis dotar a vuestra idea de mayor valor añadido, trazar un par de planes alternativos por si no funciona como teníais planeado, realizar un pequeño estudio de mercado, estudiar a vuestros posibles clientes y el entorno en el que se encuentran, si es posible contar con uno de ellos para comenzar, compartir los riesgos con un sponsor puede ser una buena idea, estudiar a vuestra competencia antes de actuar, el mercado al que va destinado vuestro producto, compartir vuestra idea con alguna persona con experiencia en el sector para obtener otros puntos de vistas y evaluar los posibles riesgos que pueden aparecer y que de otro modo desconoceríais. Así mismo es muy importante rodearse de un equipo adecuado, contar con personas preparadas que sean innovadoras, proclives al cambio y que compartan la línea de negocio de la empresa. Es también muy importante que los miembros del equipo mantengan una buena relación y tengan un nivel de educación aceptable. En el área del desarrollo, el tiempo es un factor determinante, apostar por desarrollos de larga duración es un riesgo muy alto, es mucho mejor resolver las necesidades básicas y posteriormente ir incrementando la funcionalidad y optimizando el producto, esto permitirá retornar la inversión más rápido y disminuir vuestros riesgos.
En resumen, ‘pensar antes de actuar’, ‘vender antes de producir’, ‘innovar’, ‘apostar por el valor del equipo y la colaboración', ‘reducir vuestros riesgos’.
Espero que mis experiencias os ayuden a no cometer los mismos errores, si lo logro, habré fracasado con éxito.

Recursividad con Sql Server

Una función muy interesante de Sql Server es la de poder seleccionar un conjunto de datos de forma recursiva de manera que podemos obtener una serie de datos en estructura de arbol.

Partimos de una tabla que tiene dos campos, llamados clave y padre, el campo clave se relaciona con el padre para formar la estructura en arbol.

El siguiente procedimiento almacenado muestra un ejemplo de como conseguir esto:

ALTER PROCEDURE [dbo].[Usuarios_seguridad_seleccionar]

AS

BEGIN    

    DECLARE @minClave int

    SELECT @minClave = MIN(Clave) FROM dbo.Usuarios_seguridad;

    WITH UsuariosAccesos AS

    (

        SELECT top 1 us1.Padre,us1.Clave,us1.Variable,us1.Modulo,us1.Contenido,us1.Acceso,us1.Imagen 

        FROM dbo.Usuarios_seguridad us1 

        WHERE us1.Clave = @minClave

        UNION ALL

        SELECT top 100 percent us2.Padre,us2.Clave,us2.Variable,us2.Modulo,us2.Contenido,us2.Acceso,us2.Imagen 

        FROM dbo.Usuarios_seguridad us2 

        INNER JOIN UsuariosAccesos AS us3 ON us3.Clave = us2.Padre  

        WHERE us2.Clave <> @minClave 

    )

    SELECT TOP 100 PERCENT ia.Padre,ia.Clave,ia.Variable,ia.Modulo,ia.Contenido,ia.Acceso,ia.Imagen 

    FROM UsuariosAccesos ia

    ORDER BY padre, clave

END

GO

 

El procedimiento almacenado calcula el valor mínimo del nodo con la clave mas baja, posteriormente va leyendo cada nodo relacionado de forma recursiva ya que en el inner join se relaciona con el conjunto de datos definido en la clausula WiTH, finalmente devuelve el conjunto de datos en un orden determinado, el resultado obtenido es el siguiente:

De esta forma la consulta devuelve los datos de forma similar a la estructura de estos, posteriormente se cargan el tree.

Si quereis mas información sobre la clausula WITH que permite realizar este tipo de consultas podeis encontrala en http://msdn.microsoft.com/en-us/library/ms175972.aspx

Acelera Visual Studio con Discos Solidos (SSD) y Tarjetas de Memoria

Después de leer varios artículos sobre los últimos modelos de discos SSD, y con el fin de acelerar mi trabajo con Visual Studio decidí adquirir un disco SSD modelo OCZ Core Series V2 SATA II 2.5" SSD con 120 Gb, las comparativas con los últimos modelos presentados por Intel X25, decían que incluso iban por delante en cuanto a rendimiento, su coste bastante inferior, de unos 340 € frente a los 650 € de un Intel.

La primera impresión cuando lo tienes en las manos es lo poco que pesa, parece un trozo de plástico. Después de clonar el equipo e instalar el disco duro, el rendimiento no parece mejorar, es mas en algunas operaciones incluso parece más lento, consultando en los foros del fabricante, leo que hay que hacer varios ajustes relativos al cache, el servicio de indexado, desfragmentación y otros. Para los interesados dejo los ajustes aquí http://www.ocztechnologyforum.com/forum/showthread.php?t=47212, que supongo haya que realizar en todos los discos SSD. Me pregunto si algunos serán correctos, no lo tengo muy claro.

Lo curioso es que después de hacerlo las búsquedas de archivos son espectaculares, sin embargo el rendimiento general aparentemente sigue siendo muy bajo, los tiempos de compilación con Visual Studio son similares a la utilización de un disco SATA de 7200 rpm, incluso en algunos casos más altos, los test de disco me decían que el rendimiento en lecturas secuenciales era espectacular, en cambio en lecturas aleatorias dejaba mucho que desear, la gran ventaja de la utilización de este disco es que la batería del portátil a pasado a durar más del doble, de dos horas a casi 5, sigo haciendo cambios en la configuración a través de regedit, pues el fabricante ni siquiera ofrece un programa de configuración, el disco tiene una conexión USB para actualizar el firmware, pero este brilla por su ausencia, lo curioso es que antes de comprarlo estuve leyendo en varios post, que los resultados obtenidos con este tipo de discos pasaban por un aumento de rendimiento en torno a un 30 % frente a un disco SATA Normal, en resumen toda una decepción, espero que con alguna actualización y soporte de Windows 7 para discos SSD el rendimiento pueda mejorar, pero no lo tengo nada claro.

Quizás, para trabajar con herramientas de diseño grafico como autocad que maneja archivos grandes el rendimiento mejore, pero en mi caso con Visual Studio me temo que con la cantidad de archivos que tiene la solución y el tamaño de estos que normalmente no supera 20 Kb no sea así. Lo cierto es que estoy bastante decepcionado con este disco, esperaba al menos cierta mejoria en el rendimiento tal y como se comentaba en los artículos.

Por otra parte acabo de renovar mi antiguo PC, un AMD con doble núcleo de los primeros que salieron al mercado, 4 Gb de Ram y un disco serial ata de 250 Gb, adquirí un equipo DELL Optiplex 960 con un procesador Intel Quad Core, 8 Gb de Ram, Vista 64 y un disco SSD de 64 Gb de la marca Samsung.

Como sabéis Visual Studio no permite realizar cambios en tiempo de ejecución cuando estas depurando en 64 bits, no entiendo porque ni despues del Sp1 han incoporado esta característica que es verdaderamente importante. Como trataba de potenciar el rendimiento decidi renunciar a esta opción.

Con esta configuración los resultados son espectaculares, se reduce el tiempo de compilación en un 70 %, el equipo abre outlook en decimas de segundo, realmente espectacular, el disco utilizado tiene la mitad de capacidad que el primero, pero en rendimiento nada que ver, impresionante, hay que tener en cuenta de que el procesador tambien hace su trabajo en el proceso de compilación los cuatro procesadores no bajan del 60 % de rendimiento, el sistema operativo es de 64 bits, el uso de memoria no sobrepasa los 4 gygas. Resharper y Devexpress van como un tiro. Es increíble que en un equipo que ronda los 1200 €, el rendimiento haya mejorado tanto, la verdad merece la pena la inversión.

Aprovechando este post, he realizado otra prueba utilizando una tarjeta de memoria de 4 Gb, similar a esta http://www.gigabyte.com.tw/Products/Storage/Products_Overview.aspx?ProductID=2180 Desconozco la marca de la tarjeta que tengo ya que la consiguió un compañero a través de unos proveedores directamente en china, la de la foto es de la marca Gygabyte y es practicamente identica a la mia exceptuando la bateria que es una pila normal recargable de 1,5 V, En España todavía no he visto ningún sitio donde se comercializa.

Esta tarjeta te crea un disco virtual de memoria, esta sustentanda por una pequeña batería de litio que se recarga a través del slot PCI, para evitar perder los datos cuando apagamos el equipo, aquí también los resultados son espectaculares, después de dejar el proyecto en el disco de memoria que tiene una capacidad de 4 Gygas, suficiente para almacenar varios proyectos, y redirigir los archivos temporales a un directorio del propio disco, las pruebas son verdaderamente asombrosas, el rendimiento en la compilación es similar al logrado con el nuevo equipo con disco duro SSD. No os puedo poner el precio de esta tarjeta, pero según he leído es cara.

Otra posible solución de bajo coste para acelerar Visual Studio pasa por utilizar memorias Flash como las que se usan en las cámaras réflex digitales de alto rendimiento, abra que ver las especificaciones de lectura(escritura, esta es una de las mas rápidas actualmente..

Se pueden utilizar como un disco mas en un portatil o se pueden conectar a traves de un interface SATA como el de la foto a cualquier PC, no he realizado las pruebas con este tipo de dispositivos, una memoria de 4 Gb similar a la de la foto no costara mas de 70 €, la de la foto de 8 Gb esta sobre los 110 € y el un interface para pc sobre los 20 €.

El ahorro de costes que puede suponer trabajar con este tipo de dispositivos puede ser espectacular, imaginar un equipo de 8 personas que compilen una media de 10 veces al día y el proceso tome unos 4 minutos, supone que podemos ahorrarnos 4 horas diarias solo en la compilación, aunque el dispositivo solo mejorase un 30 % el rendimiento, ya merece la pena realizar la inversión.

Otra solución muy interesante y gratuita para los que dispongais de suficiente memoria, al menos 3 Gygas, puede ser la utilización de este programa gratuito, https://www.cenatek.com llamado RamDiskVe, el programa crea un disco virtual utilizando la memoria ram del equipo, las pruebas que he realizado han logrado mejorar el proceso mas de un 30 %, aunque el rendimiento al guardar el contenido del todo el disco antes de apagar el equipo no es muy bueno y tiene algun problema, de hecho la versión para Windows Vista es beta, pero puede ser una buena alternativa que no nos cuesta nada probar.

En resumen, cuidado al comprar un disco SSD, no todos son iguales… los discos de memoria pueden ser una buena alternativa y si teneís memoria suficiente probar RamDiskVe.

Os dejo un video sobre el samsung SSD, tarda un poco, pero merece la pena. http://www.youtube.com/watch?v=pJMGAdpCLVg

[View:http://www.youtube.com/watch?v=pJMGAdpCLVg:540:0]

Espero que el post os resulte útil.

Calidad de código

La calidad de software engloba muchos y diferentes aspectos sobre el desarrollo de aplicaciones, que pasan desde la elección de una buena arquitectura, hasta utilización de diferentes herramientas, la aplicación de diferentes técnicas y metodologías de trabajo. Creo que todavía hoy en día, existe mucha gente reticente a apostar por la calidad de código, debido a que piensan que su coste es mayor que su beneficio.

Cuando empecé a trabajar en equipo, surgieron una serie de problemas de difícil solución, en seguida me di cuenta de que los programadores escribimos código de forma muy diferente que realiza las mismas cosas, generalmente algunos, los más experimentados solían redactar un código mas legible, mejor documentado, necesitaban menos líneas para llegar a la misma solución, ya que sus conocimientos eran mayores, esto originaba muchos problemas cuando tenian que modificar o entender el código de los demás y es aquí cuando empecé a interesarme por las reglas de estilo, fxcop y otras herramientas que de alguna forma nos permitían establecer reglas para que todos pudiéramos por decirlo del alguna forma “entendernos mejor”. Por otra parte en la depuración de las aplicaciones observe que era mucho menos costoso detectar y corregir un error en una fase temprana que hacerlo posteriormente.

Para poder entender mejor el trabajo de los otros programadores comenzamos a aplicar algunas de estas reglas, desde normas de estilo, documentación, desarrollo de pruebas unitarias, aplicación de patrones de diseño, normativas de base de datos y un largo etc. Esto empezó a facilitarnos la compresión y la modificación de programas, en poco tiempo empezamos a tener una visión muy diferente del proyecto, nos aporto más claridad y conocimiento del trabajo de los demás y nos ayudo a detectar gran parte de errores en una fase temprana del desarrollo.

Algunos de los beneficios más importantes que observo son los siguientes:

- La aplicación de patrones de diseño suponen la solución más adecuada para resolver un problema determinado. Esta ha sido elaborada y seleccionada en base al entendimiento y posibles soluciones propuestas y analizadas por mucha gente.

- La adopción de herramientas como fxcop, stylecop, resharper, coderush, refactor y otras, permiten minimizar algunos errores en la fase de desarrollo además de obligar a cumplir ciertas reglas de calidad y estilo, que de no utilizar, provocan si el desarrollador no es un experto, a cometer errores de difícil detección como fugas de memoria, aprovechamiento óptimo de los recursos, localización de código no utilizado, y un largo etc. Por otra parte si todos las adoptan nos habituamos a escribir código de una manera similar, con lo que nos será más fácil comprender el trabajo de los demás. De la información de los errores que nos proporcionan aprendemos a programar mejor, liberando y utilizando recursos adecuadamente, con lo que nuestro conocimiento aumenta. Algunas de estas herramientas cuentan con utilidades para ayudarnos a escribir el código y refactorizar de una forma mucho más rápida.

- El uso de profiles nos permite detectar cuellos de botella y otros problemas que de otra forma serian prácticamente imposible de conocer.

- La utilización de pruebas unitarias y otras técnicas de testeo, nos permiten detectar errores en una fase temprana, si no lo hacemos a tiempo a veces puede implicar que tengamos que modificar más de un módulo relacionado con este, con lo que el coste se incrementa aún más. Como dice la frase, “más vale prevenir que curar”.La ventaja de contar con pruebas unitarias de un módulo que no hemos desarrollado nosotros nos permite entender mejor el comportamiento del programa. La aplicación es más fácil de modificar ya que si alguien altera el programa, por ejemplo cambiando el nombre de un campo de un procedimiento almacenado o alterando alguna función como el cálculo de totales de una factura, detectaríamos el error mucho antes de ponerlo en producción evitando mayores consecuencias.

- Se disminuye la dependencia del equipo de desarrollo: Si el día mañana alguno de los desarrolladores no está o la empresa de desarrollo cierra, será mucho más fácil encontrar a alguien que entienda el código que cumple unas determinadas reglas. Si cada miembro del equipo escribe software de forma diferente esto se hace practicamente imposible. Si otra persona o empresa externa cumple nuestros requisitos de calidad esto permite que pueda comprender y extender la aplicación más fácilmente.

La calidad de código no es opcional, de no aplicarla el coste de nuestros proyectos con seguridad será mayor.

Pero no todo es de color de rosa, utilizar estas herramientas requiere tiempo, formación y sobre todo constancia. Realizar pruebas unitarias además de ser costoso requiere mucha disciplina y un alto nivel de desarrollo, no solamente debemos preocuparnos de tener la máxima cobertura en nuestro código, si no que debemos intentar probar todos los extremos, valores nulos y otros factores que de no realizarse disminuyen los beneficios de estas. De igual forma aprender a utilizar profiles y otras herramientas llevan mucho tiempo en formación y desde luego tienen su coste. Tampoco debemos obsersionarnos, no creo que debamos realizar pruebas unitarias y cumplir con el 85 % de cobertura en todo nuestro proyecto o cumplir a raja tabla todas las reglas que propone fxcop, resharper, coderush, utilizar reglas de estilo, realizar pruebas de carga, utilizar mock objects para crear independencia con nuestro entorno de datos, utilizar profiles para analizar hasta la más mínima señal de que algo va mal, etc, debemos comenzar poco a poco implantando alguna y habituarnos a utilizarla. Si haceís esto e invertimos un poco de tiempo en aprender a sacarles partido, os puedo asegurar que la mayoría se harán indispensables en vuestro trabajo.

Recuerdo que la primera vez que pusimos en marcha fxcopy en uno de los proyectos aparecieron miles de warnings, os aseguro que fue un autentico coñazo eliminarlos, ya que lo aplicamos en una fase media del desarrollo, nos costó bastante tiempo poner la aplicación en orden, pero aprendimos un motón de cosas sobre programación, algunas que nunca hubiéramos conocido si no llega a ser por este tipo de herramientas. Ahora no podemos vivir sin él y cuando vemos una aplicación que no lo utiliza en seguida nos damos cuenta de los errores que se cometen. Tampoco debemos obsesionarnos con la calidad, nunca seremos capaces de desarrollar el sistema perfecto, los cambios casi diarios en la tecnología hacen que esto sea prácticamente imposible, cada vez aparecen más técnicas y actualizaciones que hacen que obsesionarse por la calidad al igual que con la seguridad solo nos llevara a caer en un abismo sin fin.

Las ventajas de desarrollar código de calidad son innumerables, se facilitan la detección precoz de errores y nos permiten anticiparnos y corregirlos antes de poner el sistema en producción evitando tener que rehacer gran parte de las aplicaciones. Estas herramientas nacen con el objetivo de permitirnos mejorar en nuestros desarrollos, no quiere decir que nuestra aplicación vaya a estar libre de fallos, pero si que será mejor, que aprovechara mejor los recursos y por supuesto, que tendrá menos errores, tendremos mayor seguridad a la hora de modificar un programa y reglas de trabajo en equipo que de otra forma serian muy difíciles de controla, se facilita la escritura de código y la detección visual de errores en tiempo de diseño, ahorrando mucho tiempo a la hora de programar y depurar la aplicación.

El esfuerzo que debemos realizar para desarrollar código de calidad es grande, pero marcara la diferencia y en poco tiempo nos permitirá recuperar la inversión con creces, así que animaros, merecerá la pena.

Calidad de código

La calidad de software engloba muchos y diferentes aspectos sobre el desarrollo de aplicaciones, que pasan desde el estudio de la arquitectura, hasta utilización de diferentes herramientas, la aplicación de diferentes técnicas y metodologías de trabajo. Creo que todavía hoy en día, existe mucha gente reticente a apostar por la calidad de código, debido a que piensan que el coste que tiene es mayor que su beneficio.

Cuando empecé a trabajar en equipo, surgieron una serie de problemas de difícil solución, en seguida me di cuenta de que los programadores escribimos código de forma muy diferente que realiza las mismas cosas, generalmente algunos, los más experimentados solían escribir un código mas legible, mejor documentado, necesitaban menos líneas para llegar a la misma solución, ya que sus conocimientos eran mayores, esto originaba muchos problemas cuando tenias que modificar o entender el código de los demás y es aquí cuando empecé a interesarme por las reglas de estilo, fxcop y otras herramientas que de alguna forma nos permitían establecer reglas para que todos los integrantes de un equipo pudiéramos “entendernos”. Cuando oí hablar de calidad de software me asuste bastante, lo relacionaba directamente con calidad = burocracia, “creo que fue debido a mi trabajo con la norma ISO 9001”, en seguida me di cuenta de que era mucho menos costoso detectar y corregir un error en una fase temprana que hacerlo posteriormente.

Para poder llegar a entender el trabajo de los otros programadores se hizo necesario establecer ciertas reglas que fueron utilizadas por todo el equipo de desarrollo, desde reglas de estilo, documentación, desarrollo de pruebas unitarias, aplicación de patrones de diseño, reglas de base de datos y un largo etc. de normas. Esto empezó a facilitarnos la compresión y la modificación de programas por otros miembros del equipo. Muchas de estas técnicas aplicadas en conjunto comenzaron en poco tiempo a darnos una visión muy diferente del proyecto, nos aporto más claridad y conocimiento del trabajo de los demás y nos ayudo a detectar una gran parte de errores en una fase temprana del desarrollo.

Algunos de los beneficios más importantes de la utilización de estas técnicas son las siguientes:

- La aplicación de patrones de diseño suponen la solución más adecuada para resolver un problema determinado. Esta ha sido elaborada en base al entendimiento y posibles soluciones del problema.

- La adopción de herramientas como fxcop, stylecop, resharper, coderush, refactor y otras, permiten minimizar algunos errores en la fase de desarrollo además de obligar a cumplir ciertas reglas de calidad y estilo que de no utilizar provocan si el desarrollador no es un experto a cometer errores de difícil detección como fugas de memoria, aprovechamiento óptimo de los recursos, localización de código no utilizado, y un largo etc. Por otra parte si todo el equipo utiliza estas herramientas nos habituamos a escribir código de una manera similar, con lo que nos será más fácil comprender el trabajo de los demás. De la información de los errores que nos proporcionan estas herramientas aprendemos a programar mejor, a liberar recursos y utilizarlos adecuadamente, con lo que nuestro conocimiento aumenta. Algunas de estas herramientas cuentan con utilidades para ayudarnos a escribir el código y refactorizar de una forma mucho más rápida.

- El uso de profiles nos permite detectar cuellos de botella y otros problemas que de otra forma serian prácticamente imposible de conocer.

- La utilización de pruebas unitarias y otras técnicas de testeo, nos permiten detectar errores en una fase temprana, si no detectamos estos a tiempo a veces puede implicar que tengamos que modificar más de un módulo relacionado con este, con lo que el coste se incrementa aún más. Como dice la frase, “más vale prevenir que curar”.

La ventaja de tener pruebas unitarias de un módulo que no hemos desarrollado nosotros nos permite entender mejor el comportamiento del programa.

La aplicación es más fácil de modificar ya que si alguien altera el programa, por ejemplo cambiando el nombre de un campo de un procedimiento almacenado o alterando alguna función como el cálculo de totales de una factura, detectaríamos el error mucho antes de ponerlo en producción y evitando mayores consecuencias.

- La calidad de código disminuye la dependencia del equipo de desarrollo: Si el día mañana alguno de los desarrolladores no está o la empresa de desarrollo cierra, será mucho más fácil encontrar a alguien que entienda el código que cumple unas determinadas reglas. Si otra persona o una empresa externa cumple nuestros requisitos de calidad esto permite que pueda comprender y extender la aplicación más fácilmente.

La calidad de código no es opcional, de no aplicarla el coste de nuestros proyectos con seguridad será mayor.

Pero no todo es de color de rosa, utilizar estas herramientas es complejo y difícil, por ejemplo, realizar pruebas unitarias además de ser costoso requiere mucha disciplina y un alto nivel, no solamente debemos preocuparnos de tener una cobertura de nuestro código, si no que debemos intentar probar todos los extremos, valores nulos y otros factores que de no realizarse bien disminuyen los beneficios de estas. De igual forma aprender a utilizar profiles y otras herramientas conllevan mucho tiempo en formación y desde luego tiene su coste.

No quiero decir que debamos hacer pruebas unitarias y cumplir con el 85 % de cobertura en todo nuestro proyecto o cumplir a raja tabla todas las reglas que propone fxcop, resharper, coderush, utilizar reglas de estilo, realizar pruebas de carga, utilizar mock objects para crear independencia con nuestro entorno de datos, utilizar profiles para analizar hasta la más mínima señal de que algo va mal, etc, Esto sería lo ideal, pero si nos habituamos a utilizarlas e invertimos un poco de tiempo en aprender a sacarles partido, os puedo asegurar que la mayoría de ellas se harán indispensables en vuestro trabajo.

Recuerdo que la primera vez que pusimos en marcha fxcopy en uno de los proyectos aparecieron miles de errores, os aseguro que fue un autentico coñazo eliminarlos, ya que lo aplicamos en una fase media del desarrollo, nos costó bastante tiempo poner la aplicación en orden, pero aprendimos un motón de cosas sobre programación, algunas que nunca hubiéramos conocido si no llega a ser por este tipo de herramientas. Ahora no podemos vivir sin él y cuando vemos una aplicación que no lo utiliza en seguida nos damos cuenta de los errores que se cometen.

No debemos obsesionarnos con la calidad, nunca seremos capaces de desarrollar el sistema perfecto, los cambios casi diarios en la tecnología hacen que esto sea prácticamente imposible, cada vez aparecen más técnicas y actualizaciones que hacen que obsesionarse por la calidad al igual que con la seguridad solo nos llevara a caer en un abismo sin fin.

Las ventajas que nos ofrecen todas estas técnicas en conjunto nos facilitan la detección precoz de errores y nos permiten anticiparnos y corregirlos antes de poner el sistema en producción evitando tener que rehacer gran parte de las aplicaciones.

Estas técnicas y utilidades nacen con el objetivo de permitirnos mejorar en nuestros desarrollos, no quiere decir que nuestra aplicación vaya a estar libre de errores. Pero si que será mejor, que aprovechara mejor los recursos y por supuesto, que tendrá menos errores. Nos ofrecen mayor seguridad a la hora de tener que modificar un determinado programa y permiten trabajar con ciertas reglas de trabajo en equipo que de otra forma serian muy difícil de establecer y controlar. Algunas nos facilitan la escritura de código y la detección visual de errores en tiempo de escritura, ahorrando mucho tiempo a la hora de depurar la aplicación.

El esfuerzo que debemos realizar para trabajar con calidad de código es muy grande, pero marcara la diferencia y en poco tiempo nos permitirá recuperar la inversión con creces, así que animaros, el esfuerzo merecerá la pena.