Categoría: Programación

Prácticamente la totalidad de los libros de Ingeniería del Software están dedicados a explicar como hay que organizar un proyecto en el que intervienen varias personas y puede durar varios meses. En cambio, sería también interesante saber cual es la mejor forma de organizar y trabajar en un proyecto individual. La realidad en nuestro país es que al final un solo programador se come todo el marrón de crear un programa durante varios meses y el jefe solo aparece para tocar las narices. He encontrado un excelente artículo donde un americano se ha dedicado a recopilar una serie de trucos durante los 3 años que lleva trabajando en un proyecto en solitario.

Los consejos que da también son perfectamente válidos para convertirse en buen programador, aquí van los puntos clave según él para desarrollar un buen proyecto:

Aspectos no técnicos

• Ponerse metas personales
• Leer, leer, leer -> No solo libros técnicos.
• Tomarse descansos -> No programar más de 24 horas seguidas 😉
• Las reuniones con el jefe no todas malas, solo la mayoría
• Trabajar dentro de unos horarios razonables -> No programar hasta las 6 de la mañana
• Ponerse unos objetivos razonables -> No querer hacer el programa perfecto la primera vez
• Somos arquitectos del software. Y no arregla ordenadores o programadores rasos. -> No te pases todo el día instalando el windows al jefe

Aspectos técnicos

• Planifica, luego programa
• Buscar las herramientas adecuadas para el proyecto
• Arreglar bugs rápidamente
• Conocer los puntos flojos de tu proyecto
• La documentación es tu amiga
• Cuidar la interfaz y usabilidad del programa

¿Qué consejos daríais vosotros desde vuestra propia experiencia como programadores solitarios 😉 ?

Estas vacaciones mi hermano, al que le gusta mucho jugar encontró en una web japonesa el Tumiki Fighters. Uno de los juegos más originales que he visto en los últimos años (Últimamente solo se preocupan por crear gráficos impactantes). Es un juego de naves pero podemos ir cogiendo los trozos de las naves enemigas para ir aumentando nuestro poder. Es como una mezcla de juego de naves y el Tetris por muy raro que pueda sonar. Funciona con los Cursores y la tecla Z para disparar.

Los jugones ya tardáis en bajaros el juego y superar mis 105.200 puntos y los 111.300 puntos de mi hermano. Y para los programadores va dedicada la nota técnica que sigue.

El juego es libre y está programado en un lenguaje de programación que había oído hablar muy poco de él. Se trata del lenguaje D,e intenta conjuntar lo bueno de Java y C++ eliminando los males de ambos (Se supone que C# debería haber cumplido esta mision). Parece que promete bastante viendo la comparativa con otros lenguajes similares. Aquí teneis la web desde donde os podéis bajar el compilador tanto para plataformas Unix como Windows y aquí está la referencia completa del lenguaje. Para los valientes queda la tarea de compilar el juego para que funcione en Linux.

Ya hemos hablado en otras ocasiones sobre la crisis del software. Esta vez he encontrado una crítica feroz a la situación actual de la industria del software y la ciencia de la informática en general (Computer science). En este artículo se comenta que estamos en la época de la historia de la informática (desde los años 70) cuando menos sistemas operativos y lenguajes de programación se están creando, estamos estancados.

Comienza mostrando una comparativa entre la evolución del software en la década pasada y la evolución del hardware. Muestra el software utilizado por sistemas Linux.

Año 1990	Año 2000
CPU 33Mhz	CPU 600Mhz
32 Mb RAM	512Mb RAM
10 Mbps Ethernet	100Mbps Ethernet
Unix	Unix
Emacs	Emacs
X Windows	X Windows
TCP-IP	TCP-IP y Netscape
C	C
C++	C++ y Java

Vemos el impresionante avance del hardware en 10 años y en cambio seguimos utilizando los mismos sistemas operativos, los mismos protocolos y los mismos lenguajes de programación. Básicamente la estructura de un sistema Linux es el mismo y la forma de programar y trabajar con él también después de tantos años. Los investigadores en el año 90 trabajaban con C/C++, Emacs/Vi, Tex y siguen utilizando las mismas herramientas hoy en día. En cambio dice que Microsoft es sinónimo de innovación, y la verdad es que si comparamos las versiones de Word y de Windows del año 1990 con las versiones del 2000 es algo realmente impresionante.

Hace una crítica muy dura de Linux. Diciendo de este último que es una simple evolución de un sistema operativo de los años 70 que está matando la investigación en nuevos sistemas operativos en las universidades y empresas, está destruyendo la imaginación de los programadores e investigadores que emulan todos la misma arquitectura de Unix sin crear nada nuevo. Además la forma de trabajar y programar en linux es arcaica, lenta y se podría mejorar mucho si no nos asentaramos en unas herramientas que se usan simplemente como convención y nos dedicaramos a crear nuevas ideas.

También comenta algo que estoy viendo yo mismo en la universidad. Se hacen investigaciones muy cortas para dar unos resultados mínimos que sirvan para dar dinero a los departamentos y prestigio a sus profesores a base de escribir publicaciones en vez de software útil.

Para competir con Windows hay que innovar, crear cosas nuevas, realizar proyectos a largo plazo sin prisas por ganar dinero, crear nuevos lenguajes de programación que abran nuevas vías de creatividad.

En Mas que código Juanjo dedica un artículo a ampliar la visión que propusimos en el artículo de la programación como jardinería aplicándola al desarrollo web.

Yo extraigo de sus palabras que no tenemos los métodos automáticos para crear la estructura interna, ni tampoco para la presentación y usabilidad. Por lo que después de crear una página web deberá haber un equipo que se dedique a mejorar, maneter y dar más usabilidad a la web. Es decir, un grupo de Jardineros que harán que una web no se quede abandonada y en desuso. Los arquitectos en cambio además de un sistema para generar la estructura también tienen unas normas que determinan la altura de las puertas, altura de los enchufes, interruptores, ventanas etc. Está todo definido, no tiene que venir nadie a cambiar un interruptor de sitio, cambiar una puerta de lugar porque sino no entra la gente, cambiar la barandilla del balcón de altura porque la gente se cae. Todo esto suena algo absurdo pero a la gente que navega por internet le ocurre estas cosas cada día de forma metafórica.

Es muy probable que en informática haya que cambiar un enlace de lugar para que entren los usuarios en determinada sección por ejemplo, cambiar un botón que está situado de forma que inesperedadmente confunde al usuario, situar un texto importante en una zona más central, cambiar el sistema de búsqueda para que los navegantes no se pierdan etc.

El problema es que los informáticos no tenemos métodos para saber si un usuario se va a caer por un balcón de antemano. Tenemos que observar al usuario como se cae por el balcón para luego cambiar la altura de la barandilla . Steve Krug dedica un capítulo de su libro a explicarnos que lo más importante para crear una web usable es observar como la usan nuestros visitantes, a partir de lo cual podremos ir sacando fallos que había en la presentación de nuestro sitio que para nosotros no eran tan evidentes a priori.

Todo esto me hace pensar: ¿Es bueno para nosotros los informáticos que nuestra disciplina sea más una Jardineria del software que una Ingeniería del software? ¿Tenemos más trabajo gracias a ello (Al tener que hacer labores de jardineria) o por el contrario nuestro trabajo está desprestigiado al no ser una disciplina debidamente reconocida?

Ya hemos hablado aquí en otras ocasiones sobre el problema de encontrar una forma metódica de crear programas grandes que no fallen. Es un problema no resuelto y hay gente que está dedicando sus vidas a encontrar nuevos paradigmas y cambiar la forma de programar que tenemos, pero hay otra tendencia que consiste en resignarse y aceptar que la programación nunca será como la arquitectura o la ingeniería de caminos.

Dos de los ingenieros de java defienden esta última posición en su libro The Pragmatic Programmer. Pero también circula por internet una interesante entrevista a los autores dividida dos partes: Parte1 y Parte2.

Básicamete su argumentación es que cuando construyes un edificio tendrá el mismo aspecto que en el mapa del arquitecto y éste se queda practicamente inmutable en el mismo sitio durante años y años, solo tenemos que hacer una mínima manutención. Mientras que en un jardín plantamos las semillas y no podemos saber realmente cual será el aspecto final, debemos ir retocando contínuamente cada planta para que el jardín no se convierta en un caos. La verdad es que la metáfora del jardín se parece mucho más a mi día a día con la programación que el caso del edificio.

There is a persistent notion in a lot of literature that software development should be like engineering. First, an architect draws up some great plans. Then you get a flood of warm bodies to come in and fill the chairs, bang out all the code, and you’re done. A lot of people still feel that way; I saw an interview in the last six months of a big outsourcing house in India where this was how they felt. They paint a picture of constructing software like buildings. The high talent architects do the design. The coders do the constructing. The tenants move in, and everyone lives happily ever after. We don’t think that’s very realistic. It doesn’t work that way with software.

We paint a different picture. Instead of that very neat and orderly procession, which doesn’t happen even in the real world with buildings, software is much more like gardening. You do plan. You plan that you’re going to make a plot this big. You’re going to prepare the soil. You bring in a landscape person who says to put the big plants in the back and short ones in the front. You’ve got a great plan, a whole design.

But when you plant the bulbs and the seeds, what happens? The garden doesn’t quite come up the way you drew the picture. This plant gets a lot bigger than you thought it would. You’ve got to prune it. You’ve got to split it. You’ve got to move it around the garden. This big plant in the back died. You’ve got to dig it up and throw it into the compost pile. These colors ended up not looking like they did on the package. They don’t look good next to each other. You’ve got to transplant this one over to the other side of the garden.

¿Pensáis que la programación será siempre una disciplina como la jardinería o llegaremos algún dia a crear una disciplina ingenieril formal para crear software?

Me estoy dando cuenta en el mundo de ignorancia que vivía antes de conocer estos estándares para codificación de caracteres. El ASCII no es la codificación definitiva, hay que tener en cuenta que existen miles de lenguas en el mundo con diferentes símbolos y que ellos también quieren utilizar ordenadores.

Básicamente con Unicode podemos representar símbolos de cualquier lengua, símbolos matemáticos, científicos etc. Mientras que UTF-8 es simplemente una transformación sencilla de los carácteres Unicode para que puedan ser soportados en entornos Unix, el cual fue diseñado como no por Ken Thomson .

El estándar básico no define un tamaño para la representación de carácteres, pero lo normal es utilizar 2 bytes. Por ejemplo para definir el símbolo griego alfa, tenemos la codificación U+03B1. Normalmente en lenguajes como Java y C# los carácteres Unicode se representan desde \u0000 hasta u\FFFF

• Artículo sobre Unicode de Joel on Software (Obligatorio leerlo)
• FAQ de Unicode
• Tutorial Unicode, UTF-8 para Linux
• Tablas con todos los caráteres Unicode
• Tutorial Unicode