asserts en release

Tradicionalmente se ha dicho que los assert deben eliminarse en la compilación para release. La razón es la de siempre, la velocidad. Pongamos que en un bucle hacemos una comprobación:

for(int i = 0; i < len; ++i)
{
ASSERT(array[i] != NULL);
array[i]->method();
}

Es cierto que cada vuelta hará la comprobación y eso puede resultar caro computacionalmente (aunque en este caso con la predicción de saltos no habría agujeros en el pipeline para un funcionamiento normal). Este es un ejemplo simple, pero puede complicarse lo que se quiera.

Ahora, si miramos desde otro punto de vista, puede que no resulte tan caro. Si piensas el tiempo que te tiras buscando un error que se podría haber solucionado en poco tiempo viendo el rastro de asserts, seguro que no es tan caro.

Es cierto que en lenguajes como java, python, etc tienes los “stacktraces” que son un buen debugger, pero en C++ no es tan fácil y hay que andar con cuidado, sobretodo con punteros no válidos. Trabajando en un entorno de PC es fácil hacer debug, el entorno de desarrollo de lo pone en bandeja, ya que para cualquier pete enseguida te saca la típica ventana preguntándote si deseas debugear. En entornos como windows ce, donde no avisa al usar un puntero inválido, prácticamente es obligatorio poner unos cuantos asserts al comienzo de cada método.

En resumen, deja los assert en release :)

Cuanto daño ha hecho char*

Estoy remodelando una parte de agroguía y ya puestos estoy internacionalizando la aplicación. Lógicamente, cuando te pones a hacer las cosas, o las haces bien o no las haces, así que he empezado a tirar del hilo, eliminando todo lo no unicode que hubiese referente a mensajes de usuario.

Si ahora mismo tuviese que dar clase a cualquira sobre cualquier lenguaje de programación, lo primero que le explicaría es que hace unos años no se usaba unicode, se usaba una arcaica codificación llamada ASCII y que como mucho les llegaba para el alfabeto inglés. Bien es cierto que ascii sigue presente, pero menudo infierno.

Tengo unas 12 frases que internacionalizar, pero se está conviertiendo en un infierno, en parte por mi poca práctica, en parte porque nada estaba preparado para ello.

PD: es curioso, pero sin unicode el título de este post no podría haberse escrito correctamente :)

Stadium

Hoy toca autobombo, unkasoft ha presentado Stadium, un juego tipo track’n’field en el que solo necesitas un par de botones para jugar. En Unkasoft tenemos la mala costumbre de dar poca publicidad a lo que hacemos, ya sea por razones de secretismo absoluto, cosa que nunca entenderé o símplemente porque no tenemos tiempo *sic*, pero esta vez parece que hemos espabilado (pero poco)

El juego ha sido creado por Alberto Gonzalez (le conocerán de otros juegos como runaway2) como programador principal, diseño de Hugo Lanchares y diseño del apartado gráfico por Juanma Zarza. Ha participado más gente, pero esos fundamentalmente.

El juego es muy divertido, menudos piques hemos tenido en unkasoft (por cierto soy el puto rey en salto de longitud, 11 metros y pico), está muy bien equilibrado, tiene diferentes juegos que plantean varios retos, no solo es macharar el teclado. El apartado gráfico me parece muy apropiado, muy retro, todo se ve perfectamente y con buen acabado (como todo lo que hace juanma).

Otros análisis del juego por juanma y hugo y página de lanzamiento, compatibilidades y video in-game.

Personalmente las cosas que más me han gustado han sido los iconos de los botones, el confeti de cuano ganas (deberíamos publicar el códido del confeti :), la jugabilidad incluso en BASURAS como motorola V3, compatibilidad con blackberry de lo cual tenemos un poco de culpa félix y yo.

Cosas que me gustarían:

- Sabiendo como está el percal de mensajes a móviles, quizás debería haberse financiado la cosa con la publicidad in-game.
- Un making-off
- Multijugador bluetooth, aunque tiene un modo multi con el propio móvil.
- Ranking online. IMPERDONABLE. Teniendo infraestructura y experiencia con otros juegos (que no cito porque no sé si por condición de empleado puedo, juaz) me parece, sencillamente, un error grave ya que realmente habría incurrido en poco coste y la calidad hubiese sido mucho mayor.

NOTA: las opiniones que expreso en este blog NO son el calidad de trabajdor de unkasoft, son complemtamente personales.

Meme de desarrollo de software

He visto en el blog de charles petzold un meme acerca de desarrollo de software, al cual recuerdo de cuando yo empezaba a programar algo en windows.

Me he tomado la libertad de tomar el meme, traducir las preguntas(así que puede haber errores) y lanzarlo:

- Cuántos años tenías cuando empezate a programar
Justo en primero de carrera, tendría entre 17 y 18, aunque aún tardaría un año y pico más en tener un PC propio :).

- Cómo empezaste a programar
Con las prácticas de programación de la carrera, aunque aún recuerdo haber tecleado algún programa en un spectrum.

- Cual fue el primer lenguaje que usaste
Si no recuerdo mal ensamblador del 8086, aunque casi a la par que C

- Cual fue el primer programa real que programaste
Real, real, que yo recuerde, quizás algún pequeño juego 2D.

- Qué lenguajes has usado desde que empezaste a programar
asm x86 y motorola 68000, C, C++, java (PUAG), python, C#, VB(S) y seguramente algún pinito en otros lenguajes como perl, ruby, shell y otros, aunque realmente solo considero que sé usar en condiciones C, C++ y python.

- Cual fue tu primera experiencia profesional
Fue en una empresa del metal (realmente fue un “compañero del metal”), comencé de grabador de datos e implementé un verdadero caos en VBS y python que terminó por funcionar. Me sentí orgulloso del trabajo, la verdad.

- Si tú hubieras sabido lo que sabes ahora cuando empezaste a programar, hubieras empezado a hacerlo?

Pregunta difícil. Si es a nivel personal, no dudaría, SI, es algo divertido y que plantea retos. Profesionalmente, lo dudo, quizás si dentro de unos años, pero ahora no. Trabajo mal pagado, mal considerado, poco comprendido y en que se requieren mucho más años para empezar en comparación con otros trabajos que he realizado. No pasa un mes sin que piense en irme a hacer otra cosa, aunque quizás no sepa… :_(

- Si tuvieras que decir una sola cosa de las que has aprendido a lo largo de los años a un nuevo programador, qué le dirías:

Le diría dos, Trabaja duro y nunca hagas caso a los que ten consejos.

- Qué es lo más divertido que has programado?

Pues no sé si algún que otro proyecto 3D en lo personal y en lo profesional me gustó mucho un trabajo que hice para controlar pivots, que por cierto aún no he terminado y aún no me han pagado. La relación hardware y software me ha llamado la atención siempre, quizás por ello he disfrutado mucho con agroguía, aunque últimamente no tanto.

- A quién le pasas el meme:
A todos los de mi trabajo: félix, JM, Antonio, Carlos, Jaime, Edu, Alberto y Alfredo (a ver si se anima el blog de unkasoft y nos quitamos un poco de presión), elvis (enhorabuena por el artículo en shaderx), vicente (anímate a mostrarte al mundo :P), a la gente de planet statos (venga zaelsius, aunque quieras ser project manager…).

El problema del feedback

Últimamente estoy un poco obsesionado con el feedback y no en especial con la información que me llega, que eso es tema para otro post, si no por la información que soy capaz de usar de forma adecuada.

Parto de la premisa de que no soy una persona tipo seguramente para nada de lo que desarrollo y es muy posible que lo que para ti sea la feature del siglo, para los demás sea algo que está ahí, pero que le importa muy poco.

Recientemente me ha pasado. He creado una herramienta para exportación de datos de agroguía al PC, de forma que en google earth puedes ver los trabajos realizados. Para mi la feature mola la leche, pero a los agricultores parece importarles muy poco. Lógico, ya que no suelen usar el PC para hacer este tipo de cosas (salvo excepciones), así que era de esperar.

¿Es una __cagada__ o una pérdida de tiempo? pues posiblemente comercialmente lo sea, por lo menos en este momento. Podría haber invertido ese tiempo en una feature más solicitada? seguro que sí y además seguro que gracias a esa feautre podría haber vendido más, pero y lo importante que es estar contento con lo que haces? y el feedback que puedo obtener de esos datos? Como dice Steve Jobs, espero poder algún día unir puntos hacia atrás. También opino, aunque sea una osadía nisiquiera comparar mi afirmación con la suya, que tarde o temprano todo lo que has aprendido/hecho servirá para algo.

Me voy a dar un paseo por el campo a darme feedback y despejarme un poco, se encuentra cosas curiosas:

- Un conejo a 2 metros de mi, con lo asustadizos que son:

- Hay cosas curiosas, cosas que todos los días ves y nunca te paras a pensar. Últimamente me ha dado por los pivots de riego… en esta foto se ve perfectamente como las bocas de más lejos echan más agua sobre el cultivo, parece lógico si piensas el área que cubre cada una sabiendo que al proporción de agua debe ser constante (o no, imaginemos que tenemos mapas ed rendimiento…)