Cliente Vs Programador

Los informáticos tenemos la mala fama (aunque a veces merecida) de que cuando tenemos que hacer un programa a medida tendemos a hacer las cosas como nosotros parecemos que es mejor pasando totalmente de lo que el usuario nos ha pedido que haga ese programa. Creo que este chiste gráfico lo representa muy bien...

De aquí que cuando algún cliente nos pida un proyecto a medida lo que deberiamos hacer es sentarnos y hablar tranquilamente y el tiempo necesario sobre que es lo que el cliente necesita exactamente, no sobre lo que nosotros creemos que necesita.

12 señales para saber si eres un buen programador

El escrito original está en la pág web de Digg y el texo traducido se ha sacado de mundogeek
Lo espongo aquí porque también lo considero interesante.

1. Java es todo lo que necesitas.
No ves la necesidad de usar ningún otro lenguaje, ¿por qué no se puede hacer todo con Java? No te importa ver código en Python o Ruby que logra en 10 lineas lo que llevaría varias hojas de código Java. Además, seguramente las nuevas características de la próxima versión del lenguaje lo arreglaran de todas formas. (Esto es aplicable a casi cualquier lenguaje, pero ocurre que entre la comunidad Java parece estar más extendida esta forma de pensar)

2. El término "enterprisey" (NT: se trata de un término sarcástico utilizado para designar productos complejos más allá de lo necesario) no te suena a broma.
"Enterprise" no es sólo una palabra, es una filosofía, una forma de vida, un camino a la iluminación. Cualquier cosa que pueda ser escrita, desplegada o actualizada con un trabajo mínimo es descartada como un juguete que no "escalará" para futuros usos. Mientras tanto la mayor parte del trabajo real en tu oficina se hace enviando hojas de cálculo en Excel mientras esperan a que termines de construir tu nueva visión corporativa.

3.Te opones férreamente a las funciones/métodos de más de 20 líneas de código.
(o 30 o 10 o cualquier otro número) Lo siento, algunas veces una función larga es justamente lo que necesitas. Normalmente las funciones cortas son más sencillas de entender, pero algunas veces se pueden expresar más fácilmente en una sola función más larga. El código no debería hacerse más complejo sólo para adecuarse a criterios arbitrarios.

4. "¡OH DIOS MÍO! ¡PATRONES!"
Los desarrolladores que buscan constantemente la forma de aplicar patrones a cualquier problema de código con el que se encuentran están añadiendo una complejidad innecesaria. Lejos de ser algo que busques, deberías sentirte mal cada vez que tienes que utilizar un patrón de diseño, significa que estás escribiendo código que hace las cosas más complicadas y que puede ser de dudosa utilidad. Pero, ¡ey!, tu código tiene patrones, bien por ti.

5. Los ciclos de CPU son un recurso precioso y tu estilo de programación y lenguaje reflejan esas creencias.
Hay montones de problemas en los que tienes que tener muy en cuenta el consumo de CPU (modelado/simulación, procesado de señales, kernels de sistemas operativos, etc), pero no es tu caso. Para la mayor parte de los desarrolladores de software sus principales problemas de rendimiento están relacionados con las bases de datos y la entrada/salida. El único efecto de optimizar tu código para mejorar el uso de CPU será disminuir en 2 milisegundos el tiempo necesario para la próxima consulta a la base de datos. Mientras tanto el desarrollo de la aplicación se hace más lento, no puedes hacer frente a los nuevos requerimientos y te encuentras con problemas serios de calidad. Pero al menos estás ahorrándote montones de ciclos de CPU… eventualmente.

6. Piensas que ninguna función/método debería tener más de un return.
Esta la he oído alguna que otra vez, y normalmente la razón que me dan es que el código es más sencillo de analizar. ¿Según quién? Yo encuentro más fácil de leer un código más simple, y normalmente el tener más de un return simplifica el código.

7. Tus usuarios son estúpidos. Realmente estúpidos.
Simplemente no puedes creer lo estúpidos que son, olvidándose constantemente de hacer las cosas más sencillas del mundo y cometiendo errores tontos al usar tu aplicación. Nunca has considerado que quizás es tu aplicación la que es estúpida porque eres incapaz de escribir software decente.

8. Te enorgulleces enormemente del gran volumen de código que escribes.
Ser productivo es bueno, desafortunadamente escribir montones de líneas de código no es lo mismo que ser productivo. Los usuarios nunca comentan "Guau, este programa puede ser difícil de usar y estar lleno de errores, pero al menos sé que hay un montón de código por debajo." En lugar de ser productivo, generar toneladas de mal código retrasa a los demás desarrolladores y en el futuro su mantenimiento constituirá una pesada carga.

9. Copiar y pegar es genial, te ayuda a escribir código desacoplado.
Defiendes tu uso del copy paste con extraños argumentos sobre desacoplar código y eliminar dependencias, mientras ignoras el aumento del tiempo de mantenimiento y los problemas de duplicación de errores. A esto se le llama "racionalizar tus acciones".

10. Piensas que la gestión de errores consiste en capturar todas las excepciones, registrarlas, y continuar como si nada.
Eso no es gestionar errores, eso es ignorar errores y es el equivalente semántico al "on error next" de VB. Sólo porque hayas registrado el error en algún sitio no significa que lo estés tratando. Tratar errores es algo duro. Si no sabes qué hacer exactamente cuando te encuentras con un cierto error, simplemente deja que la excepción se propague y que un nivel más alto del código lo trate.

11. Modelas todo tu código en UML antes de escribirlo.
El modelado entusiasta de UML se lleva a cabo normalmente por aquellos que no escriben demasiado código, sino que se consideran arquitectos de software. Las herramientas de modelado atraen más a aquellos que piensan que el código se puede escribir en una sala de conferencias manipulando pequeños gráficos. Los gráficos no son el diseño, y nunca serán el diseño, para eso está el código.

12. Tu código borra datos importantes.
Escribiste un cierto código que se supone que debe sobrescribir los archivos de la aplicación con otros nuevos, pero se vuelve loco y borra todos los datos del usuario.

Windows ReadyBoost... mas RAM para el PC

Cuando era pequeño, yo como la mayoria de los niños, cuando recibia un regalo iba a todo correr a abrirlo. Lo que me diferenciaba del resto de los niños era que si el regalo llevaba un manual de instrucciones o de uso, me gustaba mirarmelo para ver que es lo que "habia de nuevo".
Bueno, pues eso es lo que me ha pasado con mi nuevo Pendrive, en particular con el modelo JetFlashV30 de 8Gigas. Leyendo las propiedades de este PenDrive el manual indica que es compatible con ReadyBoost, pero... ¿Que es ReadyBoost?

ReadyBoost es un nuevo concepto en cuanto a ampliación de memoria se refiere. La idea básica consiste en poder ampliar la memoria del PC usando un Pendrive. ¿Y como se consigue esto? Facil, el acceso a la memoria del pendrive es mucho más rápido que acceder fisicamente al disco duro por lo que los señores de Microsoft han hecho que en Windows Vista se pueda hacer precisamente esto, ampliar la memoria del ordenador pinchando un pendrive a un puerto usb aunque hay que puntualizar que la memoria que se añade pasa a formar parte de la memoria cache del windows en particular.

Vamos a ver como se activa esto. En mi caso como he dicho al principio he realizado las pruebas con un PenDrive de la casa Transcend, en particular con el modelo V30 de 8Gigas.

Lo primero que hay que hacer (lógicamente) es pinchar el PenDrive a un puerto usb. Una vez windows lo detecte y nos avise de que este está listo para trabajar.

Si no tenemos ninguna acción predeterminada para el dispositivo nos aparecerá la siguiente ventana donde vemos que tenemos la opción de "Aumentar la velocidad del sistema con Windows Ready Boost":



En nuestro caso, cancelamos esta ventana y nos vamos al Explorador de Windows y en el dispositivo correspondiente al pendrive hacemos click con el boton derecho-->propiedades. Debería aparecer una pantalla como esta:


Aquí están las opciones para configurarlo. Lo primero seria marcar "Usar este dispositivo" y lo segundo indicarle cuanto espacio del Pendrive dejamos que Windows use para la cache de sistema aunque por defecto el ya nos propone la cantidad que debería ser.

Hay que tener en cuenta que la memoria que se usa del PenDrive no aparece sumada a las propiedades del sistema.

Como último comentario, todo lo visto con respecto al PenDrive también se aplica a las targetas de memoria SD (Secure Digital).

YA.COM y su router Arcadyan AR4505

Hemos añadido la primera aplicación en descarga gratuita para todo el mundo. Se trata de ARFYR (Arcadyan Reset For YACOM Routers) que te premitirá evitar esos "cuelgues" del router Arcadyan AR4505 que YA.COM regala al darse de alta (si, ese que es como el de SMC pero que no lo es).

La aplicación la podreis encontrar en la sección de descargas (www.softproman.es) y aquí os dejo un pantallazo.

Gestor de metadatos

Estamos trabajando en una herramienta externa para agilizar las actualizaciones de los metados para las siguientes bases de datos: MYSQL y SQL SERVER.

Esta herramienta está pensada para facilitar y centralizar aquellas aplicaciones que tienen múltiples scripts para generar sus actualizaciones.

¿Existen TPVs para peluquerías?

Actualmente disponemos de un sencillo pero útil TPV (Terminal punto de venta) especializado en peluquerias. Este software, permite agilizar todas las gestiones típicas de este sector.

En un futuro próximo, sacaremos la nueva versión del TPV donde incorporará gran variadad de mejoras tanto en funcionalidad como de aspecto visual.

Actualmente utiliza como gestor de base de datos MySQL y en un futuro podrá soportar también las versiones de SQL Server.