RTS procedural

Estaba viendo los resultados de la compo de Tigsource sobre juegos con contenido procedural y bajandome los más llamativos me encuentro con Dyson. Se trata de un juego de estrategia, donde hay una serie de asteroides que tenemos que colonizar con una especie de moscas. En cada asteroide plantamos una serie de árboles (L-tree claro está) que nos permiten generar más moscas. Para colonizar un asterisco asteroide hay que enviar una cantidad suficiente de moscas… el juego no deja de ser lo mismo que todos los RTS actuales, una serie de recursos para generar unidades y conquistar más recursos.

El juego es simple, pero muy adictivo, además el apartado gráfico cumple perfectamente, da gusto ver como se mueven las moscas como un fluido cuando tienes más de 100. Merece la pena probarlo.

A ver si sacan los resultados y pruebo los mejores juegos porque en la compo hay demasiados juegos para probarlos todos.

Metodologías: ¿sí o no?

Llevo un tiempo leyendo algunos libros y artículos sobre metodologías además de estar dentro de un proceso de adaptación a CMM2. La gestión de proyectos es compleja, por lo menos desde mi visión actual con más bien escasa experiencia, y aún no tengo muy claras las cosas.

Resulta que el objetivo del desarrollo es tener algo tangible, algo que se pueda usar, que sea útil y en el que cuanta menos burocracia haya mejor. Esto es aplicable no solo al desarrollo de software, si no a cualquier proyecto, pero yo no sé que pasa que en todos los proyectos/negocios que veo al final se consume más tiempo en burocracia que en desarrollo.

Si tienes una empresa de 100 empleados parece lógico que la burocracia aumente, sobretodo porque con 100 empleados tienes mucha probabilidad de que tengas a mucha gente no muy buena en su trabajo, poco motivada, etc. Es normal que se tengan que marcar unas reglas estrictas de funcionamiento.

Me planteo si de verdad usar metodologías muy severas aporta algo a proyectos dinámicos, los cuales se adaptan de forma rápida a las necesidades o si estoy confundido y es necesario un control muy cerrado para llevar un proyecto a cabo con una calidad profesional.

Al final creo que el camino se hace al andar, que las metodologías describen los procesos que se han ido mejorando a lo largo del tiempo y que de verdad han demostrado que funcionan después de probar variantes, ver el resultado y sobretodo cargarla. Al final si el equipo es bueno y estila buenas prácticas la metodología aparece sola.

Me recuerda a una frase que leía en una bodega de un familiar: “una buen vino puede arreglar una mala comida y uno malo estropear una buena”

Bugs en la centralita de mi coche

Cuando hablamos de un bug en una aplicación para dibujar hablamos de una pequeña putada, llega grafista, dibuja un logotipo de muerte y tras 3 horas intenta grabar y la aplicación casca. No pasa nada, el grafista pierde 3 horas de su vida, se cabrea y listo. Si hablamos de un software que se ejecuta en un hardware que controla un vehículo, un avión o un sistema donde se hacen transacciones bancarias la cosa cambia. Un error puede matar a una persona que circula en su vehículo y pierde los frenos.

Dada el impacto que puede producir un error en un software de estas características cabe pensar que los desarrolladores de estas aplicaciones estén muy formados y que las pruebas de calidad que pasen sean muy minuciosas.

Hace unos días me llegó una carta certificada de Renault, indicándome que tenía que llevar mi coche a un concesionario oficial para hacerme una reprogramación por peligro de “bloqueo del motor durante su utilización”. No creo que después de 50mil kilómetros me vaya a petar el motor, aunque quien sabe. En resumen, me ha cambiado el software que controla la inyección de carburante, que suena importante.

Me imagino que el software de inyección irá en un hardware aparte que el ordenador de a bordo, el cual me estima mi consumo instantáneo, medio, etc. Bien, después de este reinicio ahora el coche no calcula bien el consumo medio, lo que me hace pensar que el software de mi ordenador de a bordo no se ha enterado de la reprogramación del software de inyección y por tanto sigue teniendo “algunos” datos antiguos y algunos otros nuevos. En resumen, mi consumo medio es 0.1 litros/100km (al precio del gasoil es una ganga).

Pero bueno, es un caso muy raro, se puede tolerar, sin embargo hay otro problema que me da más que pensar: 2000 kilómetros antes de cambiar el aceite me avisa y justo cuando llega ese aviso el ordenador curiosamente corrige otro bug, este es de la máquina de estados que controla lo que se muestra en pantalla. Cuando me ha avisado siempre vuelve a la pantalla a la que estaba después de usar el regulador. Cuando pongo el regulador en la pantalla me muestra la velocidad y en su funcionamiento normal se queda fijo, sin embargo, como digo, después del aviso vuelve a mostrarme lo que tenía. Esto me dice dos cosas:

1.- Los que prueban y programan no saben el comportamiento que debe tener, de otra forma se hubiesen dado cuenta de lo que tenía que pasar.

2.- No usan ningún tipo de test y si lo hacen no tienen un informe de cobertura de test. En caso de que lo usaran podría haber detectado rápidamente que el caso de funcionamiento con aviso de ir al taller estaba testeado. Un artículo referente a esto en el blog de testing de google.

No quiero ni decir nada acerca de algún que otro código que he visto que controla ciertas transacciones con tarjetas de crédito, ahora me da miedo real pagar con tarjeta de crédito.

Para cuando un coche donde dejen el código fuente abierto y cada uno podamos programarnos nuestro software a medida ? :D Hay gente que hace hacks (con arduino por cierto), pero no lo veo muy claro

pd: la imagen está tomada de la wikipedia en inglés

Manual rápido de programación con GPS

Hace tiempo que tenía ganas de poner un post de este tipo, así que vamos allá. Pongamos que no sabes lo que es GPS y quieres hacer una aplicación que necesite saber donde estás, estás en el sitio correcto, voy a tratar de enumerar lo que necesitas saber de forma clara y concisa:

- Qué es GPS: es un sistema que permite saber en qué posición del globo estás situado
- En qué se basa: Hay una serie de satélites orbitando que emiten señales, el receptor las interpreta y gracias a triangulación determina tu posición
- Necesito saber triangular: no, el receptor hace todo por tí, olvida a doppler, trigonometría, etc :)
- qué información da el GPS: te da la posición gracias a la latitud y longitud, esto es, lo hace en coordenadas polares. Además el GPS da mucho más información…
- Cómo me da la información el GPS: usa NMEA, un protocolo de texto separado por comas donde viene la información bien clarita.
- Cómo recojo la información del GPS: pues normalmente a través de puerto serie… “pero mi receptor GPS es bluetooth”, no te preocupes, tu bluetooth se comportará como un puerto serie.
- Cómo uso la información desde mi aplicación: abres el puerto y vas leyendo linea a linea los datos NMEA, extraes la información y la usas, por ejemplo, para poner un punto en un mapa.
- Las coordenadas polares no son útiles para mi: lógico, estamos acostumbrados a trabajar en coordenadas cartesianas (el plano XY de toda la vida). Alguien ya pensó en eso e inventó UTM, que no es más que un sistema para proyectar latitud y longitud a nuestro querido plano castesiano. En resumen, al final tendremos X e Y y con eso es muy fácil empezar a trabajar

- Ya, dicho así es fácil, pero cómo lo hago en la realidad?. Lo primero es tener un GPS, por ejemplo , como mi pc no tiene puerto serie uso un conversor USB->serie. De esta forma ya puedo acceder al GPS… cómo? pues con python y los siguientes pasos:

- instalo python
- instalo Python for Windows extensions si estoy en windows
- instalo pyserial que nos da acceso al pueto serie.
- instalo pygps: este hará el trabajo de interpretar NMEA y proyectar a UTM por nosotros

- abro el editor y programo:

import serial;
from threading import Thread;
from NMEA import NMEA;
from LatLongUTMconversion import LLtoUTM;

class GPSPosition(Thread):
    def __init__(self, callback):
        Thread.__init__(self);
        #serial conf
        s = serial.Serial()
        s.baudrate = 4800
        s.port = “COM1” 
        s.open();
        self.serial = s
        self.nmea = NMEA();
        self.callback = callback
        self._run = 1;
        self.start();

    def end(self):
        self._run = 0;
    def run(self):        
        while self._run:
            nmea_data = self.serial.readline();
            self.nmea.handle_line(nmea_data);
            zone, easting, northing = LLtoUTM(23, self.nmea.lat, self.nmea.lon)
            self.pos = (easting, northing);
            self.callback(self.nmea.lat,  self.nmea.lon, self.pos, self.nmea.mode > 0);

if __name__ == ‘__main__’:
    def position(lat, lon, pos, valid_pos):
        if(valid_pos):
            print ”current position”, pos, “lat: “, lat, “ lon:”, lon;
        else:
            print ”invalid position
  
    gps = GPSPosition(position);
    

ejecuto:

C:\temp>c:\Python25\python gps.py
invalid position
invalid position
current position: 314418.53, 4575413.58 lat: 41.31 lon: -5.22
current position: 314418.53, 4575413.58 lat: 41.31 lon: -5.22
current position: 314418.80, 4575413.20 lat: 41.31 lon: -5.22

- qué es posición inválida? Pues resulta que un GPS no sabe su posición nada más conectarse, necesita un tiempo (que depende de muchas cosas) para tener una posición válida.
- Lo hago y no me funciona: sal a la calle porque en casa el GPS no es capaz de coger señal de satélite dentro de casa!!
- No me da bien la posición: Lo habitual son 10 metros de error como mucho, normalmente está entre los 2 o 3 metros.
- Lo hago pero me oscilan las posiciones: en GPS es bueno pero milagros no hace.

Fin, espero no haberme dejado nada.

falta de profesionalidad

Todos los días empresas nos prestan una serie de servicios a cambio de un dinero, sea de forma directa, voy a un bar, pido un café y pago al camarero, o de forma indirecta, voy por una autovía que se financia con los impuestos que pago. Detrás de esas empresas y servicios hay gente, personas y el trabajo de esas personas es lo que al final te llega: el camarero me sirve el café, el ingeniero diseña la carretera y el operario la cubre con asfalto, etc.

El problema es que en una empresa hay gente profesional y gente que no lo es y es es la diferencia entre que no te enteres de que te están prestando un servicio a estar quemado e indefenso.

Para mi un profesional _no_ es una persona que tenga mucha experiencia o conocimientos en un área o que haga muy bien tal o cual cosa, para mi ser un profesional es ser serio en el trabajo, cumplir con los plazos, tratar de mejorar cada día, hacer frente a los problemas y, sobretodo, hacerse responsable cuando las cosas no se hacen bien.

Últimamente veo como la profesionalidad cada vez es menor: los servicios técnicos pasan de ti cuando hay un problema, el fontanero tarda 4 días en venir a repararte el agua caliente, acuerdas un plazo y luego no se cumple, etc, etc… y lo peor, cobran con un verdadero profesional. Estoy harto de ver gente que está en su trabajo viendo pasar el tiempo para que lleguen las 3 de la tarde y saliendo del paso como pueden y con el menor esfuerzo posible, lo veo cada día.

Da gusto ver a una persona que es profesional, que le gusta su trabajo y que se preocupa, y aunque me cobre más, lo pago con gusto, solo por el hecho de que sé que ese dinero va para alguien que lo merece y por otro lado porque así estoy participando en una “selección natural”.

No me extraña que las empresas cada vez busquen gente con “perfiles horizontales”, ser serio es algo básico y la carencia de esa característa es mucho más problemática que la de conocimientos técnicos. Sabes que una persona profesional que tiene una responsabilidad va a esforzarse (o apechugar) para sacarlo, independientemente de si sus conocimientos sean bajos en esa materia. Saber J2EE, hibernate, structs, blablabla tiene un precio, poder confiar en que alguien va a tener algo en la fecha, sea lo que sea, no.