18 de Mayo, 2013

Google Talk se cierra

Recuerdo perfectamente la gran noticia de que Google Talk activaba la federación en su servicio de forma que podíamos hablar con sus usuarios desde nuestras cuentas XMPP en otros proveedores (lo que llamábamos jabber por aquel entonces).

Ya era bueno que Google apostara abiertamente por XMPP para su servicio de mensajería en los tiempos en los que diferentes (e incompatibles) protocolos peleaban por hacerse con los usuarios, pero que además permitiera comunicar con otros proveedores... era una pasada.

Ese era el Google de aquel entonces, antes de que apostara fuerte a la carta de las redes sociales. ¿Recordamos el cierre de Reader? Por supuesto Google+ sigue sin ofrecer RSS; otro estándar abierto al que Google parece haberle dado la espalda. Sigue el ejemplo de otras redes sociales: los usuarios deben tenerlo fácil para generar contenido dentro del servicio, y nunca facilitar su salida.

Ahora Google unifica su mensajería bajo el nuevo Hangouts, que ya no está basado en XMPP ni en estándares abiertos :(.

El problema está en que con la unificación de servicios otras opciones como Google Talk o el chat de Gmail desaparecen, y con ellos la interoperabilidad: por ahora el interfaz XMPP sigue funcionando, pero sin federación.

Esto significa que para hablar con tu contactos con cuenta de Gmail (bueno, en realidad es Google+... porque todo converge a eso), tienes que tener una cuenta en Google. Suena tanto a Microsoft con su Messenger que no sé si reírme (digo Microsoft por ser el ejemplo clásico que marcó estilo, en realidad la mayoría de las propuestas de mensajería instantánea siguen esta estrategia). Ahora Google deja de ser especial en este punto; espero que le sirva en su batalla for las redes sociales. No sé si a Facebook le va a afectar demasiado, no parece que Google+ gane terreno.

Afortunadamente el protocolo XMPP goza de buena salud, y lo encontramos en muchos de los sistemas de mensajería que millones de personas usan a diario (mensajería corporativa, el chat de Facebook o WhatsApp, por poner algunos ejemplos), aunque sin federación se pierda parte del espíritu de un protocolo que pretendía unificar el panorama de la mensajería instantánea.

En fin, una mala noticia. Si hablabas conmigo de vez en cuando vía XMPP (sigo con mi cuenta de jabberes.org de siempre) y usas el sistema de Google, dejaremos de vernos online pronto. Al menos el correo electrónico sigue estando basado en protocolos abiertos, ¿no? Mejor no dar ideas ;).

Hay 0 comentarios, anotación clasificada en: jabber.

10 de Mayo, 2013

»¿Programas motores o juegos? · Alguna vez me he encontrado esa pregunta cuando alguien buscaba consejo sobre cómo empezar a hacer juegos, y parece que es más relevante de lo que yo pensaba. Si miramos por ejemplo la lista de juegos indie de Pixel Prospector, veremos que hay muchos juegos que usan inventos de alto nivel como GameMaker o MMF2 (ambos llevan mucho tiempo en el mercado), y los resultados pueden ser muy buenos. Claro que si te pasa como a mi que te gusta programar y tus capacidades artísticas son nulas; igual lo que te pasa es que la respuesta a la pregunta es que más que juegos, lo tuyo son los motores. ¿Tiene sentido?

Hay 0 comentarios, anotación clasificada en: programming.

5 de Mayo, 2013

»Resultados de PyWeek 16 · Ya están los resultados, ¡he quedado tercero! Mi entrada ha sido votada por 14 jueces con una puntuación final de 3.64 (3.43 en diversión, 3.57 en innovación y 3.93 en producción). El ganador en solitario ha sido Balancer Of Cirles (por delante de mi favorito: Last Will of the Emtar; más o menos la misma sorpresa que en la edición pasada porque esta vez incluso el propio autor dice que es más una demo que un juego :P), y en la categoría grupos el ganador ha sido The Sea of Good and Bad (justo ganador, en mi opinión). Felicidades a los ganadores y a todos los participantes, la próxima en Septiembre ;).

Actualización: recuerda que puedes bajarte la versión post-pyweek en: For Science! Incluye un par de correcciones y mejoras en la IA.

Hay 0 comentarios, anotación clasificada en: pyweek, python, programming.

4 de Mayo, 2013

Two Scoops of Django

Acabo de terminar Two Scoops of Django. Como el subtítulo indica, es un libro sobre las mejores prácticas con Django 1.5, de la mano de Daniel Greenfeld y Audrey Roy (que, entre otras cosas, mantienen Django Packages).

No es un libro de iniciación, y se supone que el lector tiene una buena base de Python y Django; aunque no es necesario conocer con todos los aspectos del framework. Por ejemplo: mi experiencia con las vistas basadas en clases no es muy extensa (solo las he usado para generar feeds en Atom o RSS), pero sin tener algo de idea el capítulo puede quedar algo confuso y ser mucho menos útil.

Son buenas prácticas, por lo que los autores demuestran tener una opinión muy formada en todo lo que explican, pero en general está todo muy bien justificado y, además, yo estoy casi siempre de acuerdo con ellos (con lo que seguro que tienen razón :P).

Resulta interesante ver como más o menos ya venía siguiendo algunas de las recomendaciones, y he aprendido muchos cosas nuevas y trucos que espero poner en práctica pronto.

Aunque me ha gustado mucho, el libro no es perfecto. Es corto y se lee fácilmente en unas horas, sobretodo porque está pensado como un libro de referencia y consulta, y si tiene algún capítulo que flojea un poco o alguna parte que chirría, valorando todo el conjunto creo que es un fallo despreciable.

Yo lo he leído de la biblioteca de la empresa (podemos pedir cualquier libro relacionado con el trabajo), pero no descarto comprar una copia para tener a mano en casa (quizás la segunda edición), porque creo que su mayor utilidad está en usarlo como referencia puntual hasta que puedas interiorizar toda la información que contiene para usarla cuando sea necesario.

En resumen: lo recomiendo a cualquiera que tenga ya algo de experiencia con Django y quiera mejorar sus habilidades, pero no es substituto de la documentación oficial, sino un buen complemento.

Hay 0 comentarios, anotación clasificada en: lecturas, django.

28 de Abril, 2013

Votando entradas de la PyWeek

Una vez que consigues entregar un juego en una edición de PyWeek, tienes dos semanas para votar los juegos de los demás participantes. Como conseguí entregar una especie de puzzle con componentes de estrategia, he estado probando juegos esta semana.

Ya he probado 34 de 44 entradas, y sin duda votar es lo peor de la competición :(.

La votación sigue unas reglas sencillas, pero bastante abiertas a interpretación:

  • Hay que valorar cada juego en sí mismo, y no comparándolo con otros.
  • Los criterios a valorar de 1 a 5 son: diversión, innovación y producción.
  • Si no consigues hacer funcionar un juego, puedes votar DNW (de Did Not Work; o no funcionó) y tu voto no contará para calcular el total. Esta es una de esas normas ambiguas, porque normalmente las puntuaciones son muy variables (a gustos) y un juego con muchos DNW tiene menos valores para hacer media, algo que puede beneficiar o perjudicar a la entrada.
  • Finalmente puedes votar por descalificar la entrada si consideras que no ha seguido el tema propuesto, el juego no funciona en absoluto o se han hecho trampas. Una entrada es descalificada si se llega a un 50% de votos de este tipo (algo que no ha pasado nunca).
  • Además hay que incluir un comentario, que puede servir para dar feedback, justificar un DNW, etc.

Es complicado ser consistente tras tantos juegos, especialmente cuando algunos participantes entregan cosas que no son juegos sino una demo de lo que podría ser un juego o simplemente un prototipo repleto de fallos al que no se puede jugar :(.

En esos casos el feedback es especialmente difícil y resulta un poco tedioso cuando tardas más en instalar las dependencias exactas que requiere un juego que luego el tiempo que dedicas a jugar un no-juego.

Curiosamente los juegos más acabados y con más funcionalidad parecen tener los requerimientos más simples: PyGame o Pyglet, lo que puede significar que es más importante conocer las librerías base, centrarse en la mecánica del juego y pulir el resultado que añadir azúcar de una forma más inconsistente.

Esta edición tiene muchos juegos interesantes y, aunque no tengo favoritos, sí imagino quién va a ganar (no, no soy yo :D). ¡En una semana se sabrán los resultados!

Hay 0 comentarios, anotación clasificada en: pyweek.

21 de Abril, 2013

»¡PyWeek 16 conseguida! · La elección del tema Nemesis estuvo a punto de ser eso: mi némesis. No se me ocurría qué hacer :(. Finalmente junté un par de ideas en papel y, aunque ha costado, el plan ha resultado en un juego tipo puzzle match 3 con un componente de estrategia (más o menos :P). Se puede descargar desde mi entrada en PyWeek 16 o desde la página que he montado en usebox: For Science!

Ahora a esperar los resultados de las votaciones, aunque completar una PyWeek es siempre un éxito ;).

Hay 0 comentarios, anotación clasificada en: python, programming, pyweek.

13 de Abril, 2013

»Arranca PyWeek 16 · Falta una hora y 40 minutos para que la competición empiece, así que en un rato a la cama y a empezar mañana con energía :). Mi entrada está en useboxnet3, intentaré llevar el diario al día (o al menos escribir alguna anotación más que la última vez).

Hay 0 comentarios, anotación clasificada en: python, pyweek.

5 de Abril, 2013

»Este año, de vacaciones · Así que muy tranquilo, y sin la felicitación de Google porque me he hecho a DuckDuckGo como buscador, y la privacidad es lo que tiene... que no te felicitan por tu cumpleaños ;).

Hay 0 comentarios

27 de Marzo, 2013

»El cierre de los motivadores · No es la primera vez que cierro uno de mis proyectos (¿alguien recuerda mi servicio para acortar enlaces? seguro que no :P), y siempre es una pena. Es excitante cuando empiezas con una idea y acabas publicando un servicio, como mi web para hacer motivadores; aunque siempre se te olvida que luego hay que mantenerlo ;). No es que tuviera muchas visitas, porque nunca llegó a despegar ni un poquito, pero era una tontería mantener recursos asignados a eso. Por si a alguien le interesa, hace tiempo que publiqué el código fuente (aunque es Django 1.2.5, no creo que cueste mucho adaptarlo a una de las últimas versiones -en producción tenía la 1.4.x-).

Hay 0 comentarios

25 de Marzo, 2013

(yet again) Falling Blocks

Este fin de semana he estado evaluando pyglet, pensando en usar esa librería en la inminente PyWeek. Aunque es cierto que ya le había echado un rato, creo que la descarté porque me encontré con demasiadas pegas demasiado pronto (especialmente con el sonido en Linux).

Al final fue un poco frustrante y me distraje con SDL, dejando de lado pyglet sin haber llegado ver si los problemas que me encontré fueron mala suerte o simplemente que el proyecto está menos maduro que PyGame.

La consecuencia de este fin de semana de hacking ha sido: (yet again) Falling Blocks (algo así como una vez más, bloques que caen, o ¿necesita el mundo otro juego tipo Tetris? :D). Para ser justos más que un Tetris se trata de un tributo a Columns, que mi primo tenía en su Sega Game Gear y al que eché bastantes partidas hace años.

El juego en acción
Intenté hacer gemas como en Columns, pero nada ;)

Es cierto que este tipo de juegos son fáciles de programar o, lo que es incluso más importante, se puede conseguir un aspecto aceptable incluso si tus capacidades artísticas son limitadas ;).

Ahora que he tenido un poco más de contacto con pyglet me ha gustado bastante, aunque sigue mostrando asperezas comparado con PyGame. El acceso a OpenGL en todo momento es una pasada, pero por ejemplo tener que activar el blending de OpenGL para que las transparencias de los sprites funcionen... es el tipo de detalles que te puedes encontrar y que te van a tener atascado un buen rato hasta que des con el detalle en la documentación (que debería haber leído completa, es cierto :P).

El sonido sigue siendo teniendo sus cosas, aunque con OpenAL y la próxima versión de AVbin la cosa mejora bastante (al parecer en pruebas anteriores estaba usando pulse como driver por defecto y no parece funcionar muy bien). Estoy trabajando con la versión 1.2 de pyglet, que es todavía alpha, y no he encontrado más que un par de cosillas que he podido arreglar (sobretodo en temas portabilidad cuando he intentado empaquetar el juego para Windows; ¡importante para la PyWeek!). Además esta versión incluye soporte para joysticks, que funciona de maravilla (el juego se puede controlar con un gamepad USB que tengo por aquí).

Creo que PyGame puede ser más accesible si sigues sus reglas y no vas a tocar nada de OpenGL, mientras que pyglet resulta más flexible y menos autoritario. En cuanto a portabilidad, PyGame es solo un poco mejor que pyglet (y las pegas van por el audio otra vez, recuerdo que muchas entradas de la PyWeek usaron mp3 en PyGame y la versión empaquetada en Fedora no incluye soporte para ese formato por tema patentes :S).

Así que creo que voy a usar pyglet. Aún tengo tiempo para leer la documentación y hacer algún experimento antes de que empiece la competición ;).

Actualización: he grabado una partida completa (no mi mejor partida :P, pero al menos deja ver cómo funciona el juego).

Hay 0 comentarios, anotación clasificada en: python, programming, pyweek, pyglet.

Entradas antiguas