Es por eso que en este día, quise darle unos retoques y  le agregué un reproductor de sonido del código morse generado. Es un simple acto para decir, ¡Felíz aniversario Samuel Morse!

Traductor de clave Morse (Español)

Morse Code translator (English)

Una vez tirado el tema y presentado las ideas, nosotros casi inmediatamente, acordamos el concepto del juego. Nos ayudó mucho el hecho de conocernos, ya casi sin discutir teníamos los roles y estábamos en carrera cuando volvimos a nuestros lugares.

Mientras Lautaro, un maestro del pixelart, discutía los bosquejos gráficos con Carla Corcoba, una de las pocas artistas gráficas del lugar; con Javi nos pusimos a estudiar el framework que habíamos elegido. Debo reconocer que esa era la primera vez que habíamos visto ese framework y no teníamos idea de como funcionaba. Sólo habíamos visto un par de juegos de ejemplo. Nos decidimos por ese framework, porque era web y los juegos web tienen una mejor distribución que los instaladores compilados. Pero el riesgo de esto era grande.

Gracias a la velocidad de dibujo de Lautaro, en poco tiempo ya hacíamos las primeras animaciones codificadas y empezábamos a diseñar los niveles. Dentro de las primeras doce horas, ya teníamos un prototipo bastante avanzado en donde nuestro simpático y medio bobo personaje ya corría y saltaba en un nivel precariamente dibujado.

El pixelart, más allá de ser una técnica, es una cultura. Tiene mucha historia y melancolía encima y aun sobrevive a efectos gráficos vectoriales mucho más avanzados. Nosotros lo adoramos y por eso seguimos siendo fiel a esta técnica (y a sus cientos de juegos que se siguen produciendo hoy en día).

El juego de plataforma que nosotros habíamos pensado incluía una innovación, en vez de avanzar con una sola tecla, como en la mayoría de estos juegos, hicimos que se corriera con dos, una por cada paso. Esto hacía que la coordinación fuera importante y le agregaba un toque de dificultad al juego. Una vez que el prototipo ya funcionaba nos concentramos en el resto de los componentes del juego. Las pantallas, la lluvia de meteoritos, las monedas, el sistema de puntaje, el sonido y los obstáculos que el personaje tiene que saltar y mucho testing.

Cuando ya casi teníamos todo cocinado, nos pudimos dar el lujo de hacer un nivel secreto en la primer pantalla.

A último momento nos dimos cuenta de un error importante. A Javi le parecía extremadamente fácil y a lautaro exageradamente difícil. Ya faltaban un par de horas y no podíámos saber por qué en la netbook de Javi, la lluvia de meteoros era una escasa llovizna y en la máquina de Lautaro era el diluvio universal de bolas de fuego. Hasta que dimos con la tecla: ¡Los frames por segundo! La máquina de lautaro renderizaba muchos más FPS que la de Javi. Por eso, javi rápidamente modificó el script para que todas las máquinas compartieran la dificultad y así subsanamos ese error a apenas minutos de presentar el juego. Como cereza del postre, le agregamos el envío del puntaje a facebook haciendo que apenas lanzado el juego hayan habído varios jugadores que enviaron su puntaje a la gran red social.

Despues la presentación y a jugar todos los juegos desarrollados en la jornada para evaluarlos y divertirnos.

Debo reconocer que la organización fue impecable. El lugar en la Universidad Blas Pascal era perfecto: espacioso y cómodo (teníamos toda la cantina a nuestra disposición con wi-fi y muchos enchufes), teníamos medialunas calentitas con café todas las mañanas, buen almuerzo y cena y el kiosco las 24 horas abierto para comprar azúcar, chocolates y bebidas con cafeína. Los espónsores (Nimbuzz, Intel, QAustral, Pentamedia y TripleSmart) pusieron lo suyo y además de merchandising, corrieron con todos los gastos.

Más allá de la gran experiencia y del cansancio (yo apenas dormí 2 horas en casi 50 horas que duró el evento) pudimos desarrollar Poor Little T-Rex y ganar, con éste, dos terceros puestos (el del público y el del jurado).

Gracias a los organizadores y estamos ansiosos por participar del Game Jam próximo. Acá les dejo unas fotos que tomé con mucho cansancio y sueño.

Esto se debe a que PHP tiene 2 formas de comparar datos, una compara el valor y otra también el tipo de dato. Es así entonces como
0 == false
pero
0 !== false

A continuación, listo una serie de casos para entender mejor cómo funciona la comparación de PHP con los datos booleanos. Probablemente se sorprendan con varios de estos

Las siguientes comparaciones dan verdadero (true) en todos los casos

• false == ”
• false !== ”
• false == null
• false !== null
• null == ”
• null !== ”
• 0 == null
• 0 !== null
• null !== ”
• null == ”

Otra curiosidad de yapa: count(”) devuelve 1

¿Alguno de estos casos te llamó la atención y no lo habías considerado?

No es para menos, ya que está listado entre las 50 mejores webs en tiempo real por ReadWriteWeb, empresa que este 15 de octubre organiza el evento Real-Time Web Summit a realizarse en Mountain View, California.

El nuevo diseño, creado por Elio Rivero de ilovecolors, tiene un aire fresco y armonioso. Permite usar el buscador sin caer en distracciones y, al mismo tiempo, mantiene una consistencia entre la gran variedad de contenido que muestra desde sus fuentes.

En lo personal me sirve muchísimo para seguir eventos, enterarme de los resultados de partidos de fútbol, ver que se opina sobre lanzamientos de sitios webs y ver qué se dice sobre algún tema en particular.

itPints, que ahora forma parte del grupo Pixelatom, se viene con fuerza y creo que va a dar que hablar entre los startups Argentinos, más específicamente entre los startups cordobeses.

Los temas planteados fueron desarrollados desde dos ángulos fuertemente marcados. Por un lado se desarrolló el aspecto legal del uso de internet y el email en las empresas y por el otro se desarrolló algo de lo que ya estaba más familiarizado como es el marketing digital (y social)

Estos dos aspectos fueron amalgamados después por Andrés Piazza en un cierre que abrió un interesante debate en el auditorio.

Luego de las conferencias fuimos a mandarina a cerrar la noche con una excelente tabla de quesos, una tabla de fiambres, muy buenas pizzas y por su puesto, cerveza.

Cada una de las conferencias ofreció un muy buen aporte. En lo personal, me gustó mucho el contenido de las primeras conferencias ya que el tema de la regulación del uso de internet en las empresas es difícil de abarcar y tiene factores muy sensibles en todas las partes involucradas.

Por otro lado, Fernando Arocena y su archivero físico de la revista Punto a Punto ofrecieron un panorama de cómo fue avanzando la forma de informar en los medios tradicionales.

Mario Postay, Jefe de tecnología de Brandigital, ilustró un breve recorrido de los trabajos que realiza en esa empresa y compartió con la audiencia el curioso caso del éxito que tuvieron con el fixture interactivo.

Gancé, por su parte, habló sobre el marketing digital y dio excelentes tips y una gran visión acerca del presente y el futuro de esta actividad.

Y por último, Andrés unió estos dos mundos opuestos pero interconectados, lo que derivó en la participación de varios de los presentes.

Quiero recalcar el brillante trabajo que está realizando Ageia Densi tanto en el derecho informático como en la política y gobernanza de interne. Juntar dos mundos históricamente separados como es el derecho y la informática es algo que nos beneficia a todos.

Les dejo a continuación algunas fotos que subí a mi Flickr.

Pueden encontrar más en la galería del Día de Internet en flickr

Fernando también escribió sobre este evento en la PaP.

Mientras la mayoría de los datacenters le compran los servidores a Dell, HP, Sun o IBM, Google diseña sus propios servidores con tecnología al alcance de todos nosotros. Pero su gran secreto reside en que cada uno de esos servidores tiene incorporada una batería de 12 voltios. Esto hace que su estabilidad a la hora de problemas eléctricos sea increíblemente alta y eficiente.

Además, salió a la luz que Google, almacena sus servidores en contenedores de embarque comunes y corrientes en los cuales coloca 1.160 servidores de estos capaces de consumir 250 kilowatts.

Por otro lado también se mostraron las marcas de los componentes usados y la sorpresa (al menos para mi) es grande. Usan placas madres GigaByte, 2 Discos Duros SATA Hitachi, 8 slots de memoria (no especifican capacidad) y procesadores x86 Intel y/o AMD.

Ben Jai, uno de los responsables de este gran trabajo, comentó que todo se basa en la eficiencia y en los costos. Tener una batería de 12 voltios en cada servidor en vez de un gran UPS central hace que la autonomía sea mucho más eficiente, llegando al 99,9% mientras que la eficiencia de un gran UPS puede ser de 92 a 95%.

Pero la cosa no termina ahí. La mayoría de las placas madres estándares usan entradas de 12 y 5 voltios para operar normalmente. Las de Google, en cambio, sólo trabajan a 12, ocupándose, la placa, de manejar el resto. Esto no es un capricho, sino que ha sido producto de una frenética investigación que requirió de mucha prueba, mediciones y errores. Esto logra que la fuente trabaje siempre dentro del mismo rango incrementando al eficiencia de consumo.

Todo esta información cae de manera brillante un jueves feriado donde ya casi consideraba que la semana estaba terminada. Una vez más… GRACIAS GOOGLE.

Vía CNET.

Post Relacionado: La infraestructura de Google

No tengo uno de estos anteojos, pero si algunos de ustedes es capaz de probarlo, haga una review. Me muero por saber como se ve una página estereoscópica.

Breve resumen de la estereoscopía

La estereoscopía es una técnica que recoge información o permite crear la ilusión tridimensional de una imagen. Hay varios tipos, sin embargo los más popularizados fueron los Anáglifos.

El anáglifo es una técnica que le aplica diferentes filtros a una imagen haciendo que ésta se vea un tanto distorsionada por la superposicion de colores. Estas imágenes están diseñadas para ser vistas con anteojos anaglifo que aplica un filtro de color diferente en cada ojo.

Eso es lo que Google Chrome le aplicó a su navegador. Lo puedan descargar desde acá. Incluso tiene el diseño para hacerse sus propios anteojos 3D [PDF].

Así se ve LZ con la funcionalidad de Chrome

Ese 30%, es la comisión que Apple se queda por la venta de la applicación, entonces del 100% que el cliente paga por la aplicación, 30% van para apple y 70% para el desarrollador. Sin embargo a la hora de devolver, Apple no devolvería ese 30% sino que el 100% de lo reintegrado vendría del cliente.

Este pequeño desacierto podría hacer que una aplicación para el iPhone en un país donde no tiene la madurez necesaria para entender que el software es un producto que demanda tiempo y esfuerzo, podría llevar al desarrollador a la bancarrota.

Otro obstáculo que Apple le pone a su plataforma móvil.

Vía TechCrunch