El curso tuvo dos partes: una técnica (la más extensa) y otra más informativa. Tanto Ángel como Óscar hicieron un gran trabajo, cada uno en su papel, pero siempre demostrando un vasto conocimiento de la materia. ¡Enhorabuena a los dos!

Desarrollo de aplicaciones con Qt Quick

En primer lugar, se hizo mucho hincapié en resaltar que el punto de entrada al desarrollo para móviles Nokia era developers.nokia.com, donde siempre había disponibles productos estables (las betas las ponen en otro sitio).

El seminario estuvo orientado a dispositivos móviles, aunque Qt Quick permite desarrollar aplicaciones para otras plataformas. Puesto que está basado en Qt, la formación consistió en un repaso de las principales características de éste, seguidas de una introducción práctica a Qt Quick.

En cuanto a Qt, nos hablaron del objeto base de todos los demás (QObject), señales y slots, eventos, propiedades, metadatos, gestión de la memoria (borrado en cascada), layouts para la UI, bases de datos,… para finalmente descubrirnos Qt Quick, basado en el lenguaje QML (una mezcla de CSS y Javascript) y que permite un desarrollo rápido de aplicaciones. Todo esto para simplificar el desarrollo y estrechar lazos entre diseñadores y programadores (se cambia C++ por QML, un lenguaje de más alto nivel, similar a ActionScript). Además, Qt Quick permite testear tus aplicaciones móviles en los emuladores que tiene incorporados, de forma que no es necesario disponer de los teléfonos físicamente.

Para terminar nos dieron un terminal Nokia muy bonito, en el que espero programar alguna aplicación próximamente. Tras el curso me quedé con ganas de hacer alguna cosilla. Aquí os dejo un vídeo de un juego hecho en 300 líneas de código, no está nada mal, ¿no?.

El futuro de Nokia, Symbian y Qt

Está claro que tras el reciente acuerdo de Microsoft con Nokia para utilizar Windows Phone en sus terminales, el futuro de Qt resultaba bastante incierto.

Óscar trató de convencernos de que Nokia seguirá apostando por Qt/Symbian en lo que se conoce como “next billion”, es decir, el montón de dispositivos de baja capacidad que prevén vender en los próximos años en aquellos lugares donde la telefonía móvil todavía no está tan asentada. Pero claro, la realidad es que para la gama alta, la que podría competir con los iPhones y demás, la apuesta de Nokia es por Windows Phone.

El objetivo de Nokia quedó claro: crear un ecosistema de aplicaciones y desarrolladores que aumente el valor de sus terminales. Desde luego tienen una amplia base de dispositivos vendidos, aunque la diversidad de sistemas operativos puede ser un factor bastante negativo a la hora de captar adeptos.

Update noviembre 2011: Sobre Nokia y el tema del “next billion” (¿esas pantallas no llevan Qt, no?).

Sin duda, esta industria merece un estudio detallado, pues resulta chocante que en el 2010 tuviera el honor de crecer un 6% a pesar de la “crisis mundial” de la que viven los medios y que utilizan los políticos para tomarnos el pelo, aunque ése es otro tema

Etapas del proceso productivo

En primer lugar, veamos las etapas del proceso de producción de un videojuego:

1. Idea / Concepto: estudios preliminares del diseño y el mercado, se define el framework de trabajo (consola, tipo de jugador,…) y se presenta un “sumario ejecutivo” y algunas consideraciones de marketing. Finalmente tenemos un “Project Binder” con una versión inicial de los documentos importantes.
2. Preproducción: Es la etapa clave, con una duración aprox. de 5 meses y un gasto acumulado de 1/3 del presupuesto al finalizarla. La idea fundamental es prototipar. El objetivo es determinar si se sigue adelante con el juego. En ella se demuestra el potencial real del juego, ya que dará como resultado una versión 100% jugable y publicable llamada “fpp”. Esta versión deberá responder a las 3 C’s:
• “Character”: ¿Qué controlamos?
• “Control”: ¿Cómo lo controlamos?
• “Camera”: ¿Cómo lo ve el jugador?
3. Producción: En esta etapa se desarrolla el juego completo, partiendo de la “fpp”. Tiene una duración de unos 3 meses, durante los que se trabaja en una versión “alpha”, la cual tiene un 75% de los mapas jugables, la interfaz casi terminada y todo lo necesario para poder comenzar los tests mientras se termina el 25% restante del juego.
4. Test: Cuando comienzan los tests, el objetivo es llegar a una versión “beta” que tenga el juego completo y muchos bugs ya corregidos. A partir de la “beta” se comenzará a optimizar y estabilizar la versión, pulir los últimos detalles del juego, etc. hasta obtener la versión “Master Candidate”, es decir, la versión candidata a ser máster (i.e. la definitiva, la que se distribuirá).
5. Validación (opcional, sólo aplica al caso de consolas): Una vez se obtiene la “Master Candidate”, ésta se envía al fabricante oportuno (Nintendo, Sony, Microsoft, etc,) y tras unos 2 meses apróx. te devuelven lo que se conoce como versión “Gold Master”, la cual está ya lista para ser lanzada.

Características de la industria del videojuego

• Se trabaja con las últimas tecnologías, ya que los consumidores demandan novedades periódicamente (hasta la fecha, cada 5 años se produce un cambio de generación en las consolas, con lo que ya va tocando…)
• En los 3 primeros meses tras la salida al mercado de un videojuego se producen el 60% de sus ventas. Esto se debe a que suelen ser muy esperados, por lo que se aprovecha la venta compulsiva.
• Los videojuegos están disponibles en plataformas cada vez más variadas: consolas (de sobremesa y portátiles), PCs, teléfonos móviles,… y los canales de distribución también están en proceso de cambio: steam, app store, facebook,…
• Es muy importante la Propiedad Intelectual (IP en inglés), por lo que las productoras impulsan creaciones propias, aunque también adquieren licencias externas.
• El actor más importante en la cadena de valor (si hablamos solo de consolas) son los fabricantes de consolas (actualmente los grandes son Nintendo, Microsoft y Sony), ya que definen el hardware sobre el que los publishers tendrán que trabajar. Los primeros llevan ventaja en todos los sentidos: conocen mejor la plataforma (i.e. potencialmente pueden hacer mejores videojuegos) y, además, cuando no son ellos los que crean el videjuego, los publishers han de pagarles royalties.

Otros temas tratados en el curso

No sólo de la industria trató el curso, también se dedicó una buena parte del tiempo a aprender sobre temas relacionados y a hacer ejercicios prácticos.

Por ejemplo, el primer día jugamos a un juego en equipos en el que se trataba de construir la torre más alta en 30 minutos y con el siguiente material:

• 1 metro de cuerda.
• 1 metro de celo.
• 1 nube de algodón (marshmallow).
• 20 espaguetis.

El ejercicio es muy interesante, te enseña a planificar, prototipar y rediseñar, trabajar en equipo,… diría que todo el curso mereció la pena por este ejercicio. Puedes ver una presentación sobre el reto del malvavisco (marshmallow) en la web de TED.

Por otro lado, también se dedicó un tiempo a explicar la gestión de proyectos con Scrum, donde se comentaron los siguientes conceptos:

• Product backlog: Es una lista de alto nivel que se mantiene durante todo el proyecto. Contiene items que describen potenciales características de forma poco concreta, las cuales se priorizan en función de su valor de negocio.
• Sprint backlog: La lista de trabajo que deberá realizar el equipo en el siguiente sprint.
• Daily Scrum meetings: Qué has hecho, qué vas a hacer y tienes algún problema. No más de 15 minutos.
• Tiempo de los sprints. Duración fija, de forma que sea más fácil predecir lo que va a darnos tiempo a realizar.
• Framework de scrum: reglas, ceremonias y artefactos,
• Tareas pequeñas, no más de 3 días, para que sea más fácil estimarlas correctamente.

También hicimos una planificación grosso modo del desarrollo completo de un videojuego, sin tener en cuenta una metodología completa, simplemente para ver qué roles hacen falta en el equipo:

• Programmer (motores de físicas, luces, gráficos, colisiones, sonido. Efectos especiales, menús, hud, modos de juego, inteligencia artificial, cámaras, debug,…)
• Level Designer
• Game Designer
• Sound Designer
• Data Manager
• 3D & 2D Artists (modelados de personajes, texturas y mapeados de texturas, objetos 3D,…)
• Animator

Esto es todo, si tenéis más curiosidad sobre el funcionamient de la industria, os recomiendo esta web “The Video Game Industry | Resume Play” (en inglés), donde se describe con más detalle todo el ecosistema.

La primera charla fue impartida por Teresa Oliver, no sé a qué se dedica, pero supongo que será algo así como “llevar el agilismo hasta el último rincón del planeta”. Puedes ver el vídeo completo aquí. La idea era presentar en qué consiste el desarrollo ágil y vendérselo a la gente de nogocio (de la que por cierto había más bien poca). De lo que dijo me quedo con lo siguiente:

• El agilismo es una filosofía, una forma de pensar, no le gusta que se entienda como una metodología. Además, no está limitado al desarrollo de software (aunque en el 95% de los casos sigue siendo así).
• Las “metodologías ágiles” no son para todo el mundo, hay equipos que trabajan mejor de otras formas, aunque ella cree que, en general, todo equipo se beneficiaría de seguir un proceso más abierto al cambio.
• El 64% de las funcionalidades desarrolladas en el mundo nunca se utilizan.
• Se centra en SCRUM:
  • Apuestan por reconocer que los cambios ocurren y facilitar su tratamiento.
  • Se utilizan sprints compuestos de historias que vamos a implementar.
  • Los sprints tienen que durar de 2 a 3 semanas. La planificación se hace pensando qué cabe en este tiempo (time-boxing).
  • Al principio de cada sprint se priorizan las historias según la importancia que tienen para el cliente.
  • Las historias elegidas para el sprint han de estar terminadas al 100% cuando éste termina.
  • Tras cada sprint se entrega al cliente un producto funcional (cada vez más avanzada, pero real).

La segunda charla fue impartida por Jose M. Cristobal, CTO de SevenClick, empresa aragonesa dedicada al desarrollo de aplicaciones móviles. El vídeo está disponible para visualización online. Su charla estuvo orientada a comentar lo que habían aprendido al aplicar algunas técnicas de desarrollo ágil. Muchas cosas interesantes:

• Las reuniones diarias han de ser diarias, intentaron hacerlas martes y jueves pero no dio resultado. Está claro que las standup han de ser muy cortas y no tiene sentido que participen 15 personas, pues se pierde el ritmo.
• No estimar en horas
  • Comenta la Ley de Parkinson: “El trabajo se alarga hasta completar el tiempo planificado para su finalización”.
  • Las estimaciones en horas/días son personales y cada uno tendrá la suya, con lo que no hay forma de establecer un valor absoluto. Además, las horas pendientes son irreales, ya que puedan faltar tareas o ser erróneas.
  • Ellos utilizan estimación relativa, concretamente con Planificación de Póker.
  • Al cliente no le importan las tareas que hayas tenido que hacer para completar una funcionalidad, lo que le importa es que funcione y haga lo que él espera.
• Termina lo que empieces
  • Tendencia a terminar prematuramente las tareas, sólo por acabar cuanto antes.
  • Lo que hacen es dejarse un buffer de colchón para pruebas y otras labores necesarias, pero que se tiene tendencia a no hacer por falta de tiempo.
• Pregunta al Product Manager (Cliente)
  • NO interpretar, imaginar o suponer lo que quiere el cliente. Preguntarle.
• Consejos
  • Scrum no sirve para todos. Si no encaja en tu equipo de desarrollo, es mejor usar otra metodología.
  • La agilidad no es una bala de plata. Hacen falta prácticas de ingeniería, no basta con sólo usar una metodología ágil.
  • La agilidad necesita compromiso por parte de todos los stakeholders.

Tutoriales

• Getting Started with Matlab (PDF, 2MB). Éste es sin duda el documento que hay que leer en primer lugar, es muy fácil de leer y te presenta las características más importantes del lenguaje. Además, sirve como pincelada de la potencia que tiene Matlab. Es gratuito y se puede descargar de Mathworks. Incluye las siguientes secciones:
  1. Introducción.
  2. Matrices y arrays.
  3. Gráficos.
  4. Programación.
  5. Análisis de Datos.
  6. Creación de Interfaces Gráficos de Usuario (sí, con Matlab puedes crear tu propia aplicación gráfica).
  7. Herramientas del Escritorio y el Entorno de Desarrollo.
  8. Interfaces externas.

• An Introduction to Matlab por David F. Griffiths (PDF, 1,6MB). Este documento es mitad referencia, mitad tutorial. Está bastante bien formateado y es fácil de leer. Si lo sigues paso a paso puede que te quedes con los conceptos fundamentales de Matlab, aunque quizás sea más útil como resumen rápido del lenguaje.

• Introduction to Matlab por Ela Pekalska (PDF, 500KB). Este documento se asemeja mucho al anterior, por lo que lo dejo aquí como otra opción posible, que cada cuál se quede con el que más le guste.

Referencias

• La ayuda en línea de Matlab (i.e. la que aparece al pulsar F1 y que también está disponible via web) es sin duda la mejor referencia, ya que, junto con la descripción y definición de cada función, característica o toolbox, acompaña ejemplos muy ilustrativos de uso que ayudan a poner en contexto fácilmente cada punto.

Programas de ejemplo

Sin duda, una vez que uno ha tomado contacto con un lenguaje o entorno de programación, la mejora forma de afianzar y ampliar conocimientos es estudiando código hecho por programadores con más experiencia. Existe gran cantidad de código de ejemplo en internet, aunque si tuviera que elegir un lugar, escogería MATLAB Central, la comunidad que Mathworks ha creado en torno a su propio producto. Además de programas de ejemplo, contiene foros, blogs, preguntas/respuestas y enlaces interesantes.

Otros enlaces

• Preguntas más votadas sobre Matlab en stackoverflow. Preguntas sobre Matlab de recomendada lectura.
• Enlaces más populares sobre Matlab en delicious. Como muy bien sabe Valeri Jakobs, esta herramienta puede ser muy potente a la hora de encontrar información de calidad (a pesar de haber sido comprada por Yahoo).

Por otro lado, si enlazamos lo anterior con la recomendación del libro “The Pragmatic Programmer” de aprender un lenguaje de programación al año, podría decirse que uno de mis productos del año pasado fue aprender a desarrollar con Matlab y hacerlo sobre un problema real: la detección de caras.

Matlab es un software de cálculo numérico comercial utilizado en universidades y empresas mundialmente. Se caracteriza por su facilidad y potencia para manejar matrices. Además, existe una gran variedad de librerías (toolboxes) que permiten hacer casi cualquier cosa que pueda surgir en un entorno científico-técnico.

Para programar en Matlab se puede utilizar el IDE que tiene integrado (que es bastante potente y funciona muy, muy bien) o cualquier editor de texto. El lenguaje de programación de Matlab es interpretado (aunque también puede compilarse) y de cuarta generación, i.e. diseñado con un propósito específico en mente (mis profesores de “Lenguajes de Programación” de Unizar, que ostentan el récord de menos palabras por hoja de apuntes, estarían orgullosos de mí).

En próximos posts de esta serie comentaré los recursos más útiles, ejemplos de lo que he hecho con Matlab y hasta publicaré algo de código libre

La razón es sencilla y basta echar un ojo a su mítico tutorial para descubir que el movimiento del cursor se realiza con los cuatro dedos de tu mano derecha situados sobre las teclas h j k l, es decir, donde los tendrías si fueras a escribir a máquina… con un teclado inglés

Podemos ver a continuación cuál es la posición recomendada para mecanografiar usando un teclado QWERTY con EÑE:

He estado buscando la forma de cambiar las teclas que se utilizan para movernos dentro de vim pero no he encontrado cómo cambiar el significado de las míticas teclas “hjkl”. De todas formas, sé que mucha gente utiliza vim y nunca les he oído quejarse, ¿quizá saben algo que yo no sé? ¿directamente pasan de la eñe? ¿sólo escriben en inglés?.

Actualización diciembre de 2011: Estos días ha vuelto a resurgir mi interés por usar vim como mi editor para programar, principalmente gracias a un post de Steve Losh que merece la pena leer (si quieres saber más sobre vim y te estás planteando cambiar). Por otra parte, he buscado a otros que se han planteado la cuestión descrita en este post y he visto que hay dos opciones mayoritarias: 1) Remapear el teclado, y 2) Cambiar el layout del teclado al americano cuando estás programando. Promete más la segunda opción.

Actualización abril 2012: Ha caído en mis un post sobre el origen del uso de las teclas h j k l en vi. Es interesante

De acuerdo, no siempre la empresa privada es peor que la pública, aunque podríamos decir, basándonos en información tan fiable como rumores y comentarios que, en general, resulta más tranquila y mejor remunerada; al menos aquí, en España.

Hoy estaba corrigiendo un problema de esos que tienen historia, es decir, que llevan ahí desde siempre… y he pensado que todo desarrollador de software debería pasar por un trabajo en el que tuviera que mantener aplicaciones realizadas por otros en épocas pasadas.

Igual que los funcionarios en Francia: antes de poder crear código nuevo (o arquitecturas nuevas o incluir una nueva librería o meterse en el berenjenal x), debería ser obligatorio dedicar unos años a mantener software de otros y sufrir en tus propias carnes las consecuencias de una mala decisión (o de muchas).

Y así, cuando por fin se tenga la responsabilidad de crear, se tomarán decisiones que faciliten la escalabilidad, extensibilidad y mantenibilidad del software.  ¿O quizás lo contrario, para así resultar imprescindible? Espero que no… por el bien de todos.

Si quieres saber qué pasa con otras versiones de windows o los detalles exactos, te recomiendo esta página: “Límites de Memoria para las distintas versiones de Windows”.

Sin embargo, esta limitación impuesta por el sistema puede ser incómoda, al fin y al cabo, ¿por qué 2GB y no 2,5GB? ¿y si mi aplicación los necesita?

Microsoft ya cuenta con esto y es posible permitir que el espacio dedicado al proceso sea mayor a 2GB. Tenemos que ser conscientes de que, puesto que el límite de memoria virtual son 4GB, si se aumenta la memoria reservada para el proceso de usuario, disminuirá la cantidad de memoria reservada para el núcleo.

En el siguiente post de Mark Russinovich, “Pushing the Limits of Windows: Virtual Memory” y en éste otro de Brian Madden, se explica muy bien la situación (Mark es uno de los creadores de las herramientas Sysinternals y autor del mítico libro Windows Internals).

En resumen, para que un proceso pueda utilizar más de 2GB es necesario:

1. Activar el flag Large Address Aware en el binario (para ver si un ejecutable lo tiene activado ejecutar: dumpbin /headers fichero.exe). Este flag se puede activar al linkar tu binario o posteriormente con alguna herramienta que modifique las cabeceras.
2. Arrancar el sistema con el flag /3GB que permite reservar a los procesos de usuario hasta 3GB (dejando una sola para las necesidades del núcleo del sistema).

A disfrutarlo

La idea de mezclar estas tecnologías ha sido del señor Cufón. Con su ayuda podrás generar fuentes y descargarte el renderer para incluirlo en tu web. Si quieres ver cómo queda, échale un ojo al código fuente de esta página.

Si estás usando el tema Scenic Sanity y no te salen los acentos, tranquilo, todo tiene arreglo. Como yo ya me las he apañado para buscar la fuente y volver a generarla con los parámetros adecuados, ¿para qué lo vas a volver a hacer tú? Mejor déscargate mi fichero y súbelo a tu web.

He decidido usar la versión estática de la librería para no depender de una dll, ya que mi objetivo es generar un ejecutable sin en tiempo de ejecución  (más allá de los runtimes obligatorios).

Para compilar glog basta con abrir la solution correspondiente: google-glog.sln, seleccionar el proyecto estático y compilarlo (debug y release). Después se configura en nuestra aplicación el path de los includes (google-glog\src\windows) y de las librerías (google-glog/Debug o google-glog/Release, según corresponda).

Si intentas compilar ahora, verás el siguiente error de linkado:

error LNK2001: unresolved external symbol "__declspec(dllimport)
  void __cdecl google::InitGoogleLogging(char const *)"
  (__imp_?InitGoogleLogging@google@@YAXPBD@Z)

Para solucionarlo, hay que seguir el siguiente paso no documentado: Añadir la siguiente directiva de preprocesado a las propiedades de nuestro proyecto:

GOOGLE_GLOG_DLL_DECL=

Ahora sí, podemos empezar a usar la librería… vamos a ver qué tal.