Month: August 2012

Posted on

Y leí el libro de Daigo Umehara

Aunque fue hace ya varios meses, no quería dejar de comentar en el blog mis impresiones sobre el libro que escribió Daigo Umehara.

Seguramente quienes no están metidos en el mundo de los videojuegos ni siquiera han oído hablar de Daigo. Como introducción, vean el siguiente video. Daigo es quien da la voltereta y gana el round.

[youtube]http://www.youtube.com/watch?v=kuSMEVhPvTY[/youtube]

Sí, yo sé que éste no es el principio de Daigo, y también estoy consciente de que muchos de ustedes lo vieron y no tienen ni idea de lo que está pasando. Resumiendo: lo que Daigo hace en el video es como el sueño dorado, la meta y el significado que tienen los juegos de pelea, al menos para mí. Ejecutó una jugada maestra arriesgándolo todo y terminó ganando un round y una pelea que estaba prácticamente perdida… en torneo… ¿Todavía no entienden qué onda? Bueno, sólo piensen que hizo algo muy, muy difícil.

Daigo está en el libro de récords Guiness como el jugador profesional de videojuegos que más triunfos ha obtenido en torneos oficiales de Street Fighter, y fue el primer jugador profesional de videojuegos en Japón, ya que antes de él no existía el concepto por acá.

Daigo escribió un libro que fue publicado este año. Portando el título de 勝ち続ける意志力(Kachitsuzukeru ishiryoku) que se traduce como “La fuerza de voluntad para continuar ganando” en él se plasman los acontecimientos que llevaron a Daigo a ser quien es ahora, y su filosofía de cómo ganar y mantenerse siempre en la cima, que todos sabemos que es lo realmente difícil.

Las primeras páginas del libro describen el video de arriba; Daigo narra punto por punto lo que pasó por su mente en ese momento, y quizá lo que a mí me llamó más la atención es que durante esos segundos críticos él no escuchó absolutamente nada, ni siquiera a la multitud que poco a poco comenzaba a celebrar su jugada. Según sus palabras, hasta después de terminada la pelea se dio cuenta de que la multitud se había vuelto loca. Ese nivel de concentración en una situación como esa es, al menos para mí, increíble, y al mismo tiempo un acto loable.

Obviamente, no todo fue miel sobre hojuelas en la vida de Daigo, pero siempre estuvieron presentes los videojuegos, y es ahí donde me sentí identificado. Ya antes he escrito aquí lo que significan para mí los videojuegos, y leer algo similar que viene de un personaje como Umehara fue hasta cierto punto sorprendente.

Daigo hace la separación (hasta cierto punto lógica) entre los que ganan y los que son ganadores. Hay gente que piensa que llegar a ser el número uno es la meta final; se concentran en ganar un evento en específico, o en vencer a alguien en específico, y es una meta totalmente respetable, pero esa gente no llega a ser ganadora.  Menciona también que hay que encontrar un balance entre no ser arrogante al momento de ganar ni tampoco auto-despreciarse al perder.

Algo que sí me sorprendió es que Daigo comenta que no le gusta aprovecharse de las debilidades de sus oponentes, y que no recomienda hacerlo si es que uno quiere hacerse realmente bueno.

En el libro también se cuenta sobre el tiempo que Umehara estuvo retirado de los videojuegos, y lo que hizo en ese entonces: aprender a jugar Mahjong y convertirse en 介護士(kaigoshi, enfermero dedicado al cuidado de gente mayor).

Con todo, quizá el punto en el que más estuve de acuerdo de todo el libro es en 2 puntos:

  1. En vez de concentrarse en ganar un evento, lo que se debe mantener siempre es un propósito, y ése debe ser el seguir creciendo, seguir mejorando, seguir puliendo las técnicas. Después de todo, si uno se centra nada más en llegar a la cima, lo más seguro es que alguien llegue y te destrone. A fin de cuentas, siempre habrá alguien queriendo desafiar y derrotar al campeón.
  2. Daigo expresa que estar en el mundo de los juegos de pelea implica estar aprendiendo siempre. Puedes ser el mejor en un juego, pero cuando salga otro, cuando la comunidad y la competencia se mueva, si no aprendes desde el principio, lo que va a pasar es que vas a perder, y te quedarás pensando “pero si era muy bueno en el juego X”.

El punto 2 anterior es algo que siempre he sentido, y de hecho fue lo que me motivó a comenzar a jugar Tekken, siendo que nunca me habían gustado los juegos de pelea en 3D: cuando iba al centro de juegos y esperaba encontrar reta en algun juego conocido. En 2005, publiqué aquí en el blog el resultado de la primera vez que fui a retar a las arcadias en Iizuka, pero poco a poco esa gente se fue moviendo a otros títulos. Veía que muchos se juntaban en Tekken (en aquel entonces el 5), pero yo me resistía precisamente por no haber practicado nunca. Cuando de plano me animé, me pusieron las arrastradas de mi vida y llegaba a pensar en lo “bueno” que era en otros títulos con los que crecí y a los que me acostumbré durante muchos años. Al aplicar lo que siempre hago en el mundo de la computación y la investigación, de repente la frustración se convirtió en reto… en uno que todavía sigue.

Daigo Umehara, como cualquier persona que se hace famosa, tiene defensores y detractores. Mientras los primeros lo elevan al estatus de dios de los juegos de pelea, los segundos se dedican a celebrar cada una de sus derrotas (como la que sufrió en el pasado EVO 2012 – el torneo de juegos de pelea más importante a nivel mundial). ¿Mi opinión? El hecho de estar presente en torneos y ser constante en el top 8 lo hace admirable. Puede que no gane siempre, y que no haya ganado últimamente algún torneo, pero el temple que muestra al momento de estar en escena es impresionante.

Un día de estos seguro me lo encuentro. Según su libro, siempre está en Shinjuku, desde las 5 pm hasta que cierran, excepto a fin y principio de año. Rara, muy rara vez pido una fotografía o un autógrafo a alguien, pero si lo veo, seguro haré una excepción.

Posted on

Notas rápidas al trabajar con Access

Ignoremos el hecho de que Access es MALO, pero MALO con ganas. No tengo idea de por qué no hicieron las cosas en Oracle, pero también pasaremos eso por alto.

Una pequeña lista de problemas que me he encontrado al trabajar con esta aberración. Nota: estoy trabajando con Access 2010.

  • Las consultas que usan LIKE necesitan * en vez de %. Ejemplo:
    (Mal) Select nombre from agenda where name like ‘%Medina%’
    (Bien) Select nombre from agenda where name like ‘*Medina*’
  • Lo anterior es FALSO si la consulta se envía desde fuera (en mi caso, C#).
    A fuerzas necesita el %
  • No se puede hacer un join de tablas con campos de tipo “Memo” (no me pregunten por qué tengo que hacer joins con ese tipo de información :S).
    El tipo de datos “Memo” no guarda los datos en la tabla, sino en otro lugar y la tabla contiene solamente un apuntador a esos datos. Como SQL no sabe qué onda con apuntadores, te dice que no es posible hacer el join.
  • Al parecer, al crear una consulta directamente en SQL es necesario guardarla primero antes de ejecutarla si se quiere que Access respete la indentación que le dimos. No he comprobado esto al 100%, pero sí golpeé el monitor cuando abrí una mega consulta que hice y Access me mostró todo por ningún lado, mientras que otras sí las dejaba como las había formateado.
  • No se puede poner comentarios con “–” en el SQL que maneja Access. Horrible, si me permiten el comentario.
  • Access no aguanta hacer subqueries muy pesadas. Una consulta estilo: 
    Select id from agenda 
where nombre in (
    -- Una súper consulta incluyendo más subqueries, union, left outer join, etc.
)

    hace que Access te diga “esa operación no se puede realizar en subqueries.

    La misma consulta en MySQL y PostgreSql corre sin problemas, por lo que el SQL está correcto.

Sé que soy un completo Noob en esto de Access, por lo que se aceptan sugerencias y correcciones.

Posted on

Programando “de forma normal”

La semana pasada, y de hecho también este lunes, estuvo simplemente fatal. En el trabajo aplicaron la súper estrategia de meter a alguien en un proyecto del que no tiene idea de cómo está compuesto, y le echan trabajo que, como siempre, era para ayer, sin contar que todo está hecho en un lenguaje que ese alguien nunca ha usado y un juguete que simula ser una base de datos (léase “Access”). ¿Necesito decir que ese alguien era yo?

He trabajado en desarrollo de sistemas antes y sé lo que son los tiempos que se manejan en el proceso: nunca son reales y uno tiene que andar a la carrera para poder sacar “los pequeños cambios” que curiosamente salen después de que los requerimientos fueron tomados, aceptados y congelados. Pero quizá lo que más me sorprende es la reafirmación de que en muchos lugares el software que se usa para producción dista mucho de tener una calidad siquiera aceptable, y Japón no es la excepción. Cierto. He visto código que sí está bien hecho, con buen formato y con su respectiva documentación, pero son pocos los casos.

Lo que tocó hacer estaba en C# y la base de datos en Access… simplemente increíble. El código estaba bien estructurado, pero había funciones que realizaban más de una tarea y que eran enormes; comentarios totalmente inexistentes que hacían mucho más difícil de entender lo que el programador pensó al momento de codificar. Lo grave del asunto es que, después de tanto tiempo y de haber trabajado en 3 países, ya considero esto como normal puesto que entiendo que muchas veces se anda a las carreras con tal de cumplir con los tiempos establecidos aunque tu vida social desaparezca por ello.

Justo el buen panda me envió este artículo en el que se habla de lo que aquí comento, especialmente aplicado a programas que manejan acciones de empresas y de cómo pueden hacer perder millones por un simple error. Además de los tiempos, muchas empresas no toman en consideración las pruebas ya que representan un costo extra, y es casi verdad universal que quienes manejan las empresas piensan que con ver correr el prototipo de un sistema es suficiente para decidir si funciona o no.

Aclaro aquí algo: yo también he estado en la situación de que hay que acabar a como dé lugar sin importar cómo quede el código, y estoy seguro que mi forma de estructurar programas puede mejorar. En resumen: no me creo ni soy el mejor desarrollador del mundo. No obstante, estoy completamente seguro de que muchos me darían la razón si vieran el código del que estoy hablando.

De código de investigación ni hablamos. Me da pavor ver lo que hice durante mi estancia en la universidad…

Como quieran y gusten, terminé lo que tenía que hacer en el tiempo que me establecieron, pero para lograrlo me tuve que quedar hasta muy tarde en el trabajo (el lunes salí a las 11:30 pm y apenas alcancé tren a la casa). Sin embargo, hoy ha comenzado a otra parte del proyecto, y para los tiempos que manejan no me va a quedar de otra que echarme un clavado al código ya hecho, entender lo que hace (y viendo como hay valores que pasan por referencia, como las propiedades de los objetos están definidas como públicas… y mejor no le sigo) y reusar lo que sea posible. El problema a resolver es interesante, y de hecho me gustaría pensarlo en términos de probabilidad y hasta algoritmos como el Hill Climbing, pero todo indica que no tengo el tiempo que necesito para realizar el análisis que eso implica.

Con todo, es totalmente un placer decirles que la diferencia entre mi trabajo anterior y éste es como del cielo a la tierra. Compadezco a mis ex compañeros por tener que trabajar en una situación tan estresante.

Aquí seguimos.