Eso me pasó siempre cada vez que alguien me pregunta qué framework PHP debería utilizar. Siendo que nunca me gustaron demasiado los frameworks por el simple hecho que estos te limitan el campo de acción debo reconocer que trabajar sin uno hoy en día es casi suicida.

Habiendo pasado por varios frameworks he visto cómo se suele desvirtuar el objetivo y la utilidad de un framework en nombre de la sencillez, la estabilidad, facilidad de uso y dios sabe que otra aberrada justificación.

Ejemplos como:

• Utilizar sesiones propias engorrosas y pesadísimas en pos de la seguridad (WTF) en vez de utilizar sesiones nativas del lenguaje.
• Tener que aprender a utilizar  funciones para cerrar un simple tag html como podría ser form_close() que lo único que hace es imprimir un “</form>”
• Obligar al desarrollador a usar GET o POST dependiendo sea el caso o el módulo a utilizar.

Todas estos ejemplos hicieron que no haya tenido buena experiencia en general con los frameworks PHP o los CMS mal llamado frameworks.

Es por esto que  con Pixelatom continuamos una idea que tuvo Javier y que plasmó en su LinxPHP, un framework que ofrece la estructura básica para trabajar en cualquier tipo de proyecto.

LinxPHP no ofrece, como otros, codificar menos o menos tiempo de desarrollo. Lo mejor de linx es que ofrece una estructura sólida para que un desarrollador con experiencia de programación orientada a objetos pueda demostrar lo que sabe sin tener que preocuparse por la estructura genral del sistema.

Las principales ventajas y las vertebras de LinxPHP son las siguientes:

• Un enrutador que permite trabajar con URL amigables directamente con los controladores.
• Modelos que mapean la base de datos y que crean todas los objetos necesarios para trabajar con la base de datos
• Un MVC  básico para no tener que aprender nada nuevo.

En Pixelatom venimos laburando hace más de un año con este framework y hemos realizado más de 30 sistemas y sitios webs con un éxito rotundo. Por lo que ahora, después de varias vuelta de tuercas, lanzamos el framework con licencia Open Source para que pueda seguir creciendo y alimentándose de los desarrolladores que están podridos de tener que limitarse con las funcionalidades de los frameworks monstruosos.

Es por eso que, hoy en día, si me preguntan que framework PHP utilizar, puedo decir sin preámbulos y tranquilo que LinxPHP se la banca un paquetazo.

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.

Personalmente disfruté muchísimo esta materia ya que fue mi primer acercamiento a la electrónica. Para minimizar las entradas de energía utilizamos los famosos mapas de karnaugh y, después del segundo intento, tuvimos nuestro circuito funcionando.

Hoy, 7 años después, encuentro este simulador de compuertas lógicas desarrollado en flash. Me pareció genial y muy útil a la hora de probar circuitos lógicos, especialmente usando los mapas de karnaugh.

Sigan el link (ahora movido aquí)y podrán jugar ustedes mismos. Lo único que creo que le hace falta es un “save” para poder seguirlo trabajando después. El resto está fantástico.

Se trata de una búsqueda personalizada… pero me dio mucha gracia.

A raíz de eso, mejoré la versión anterior y basé su funcionalidad en Ajax. De esta forma la traducción se hace de forma inmediata y sin necesidad de clickear nada. Además le agregué un pequeño (a mejorar) detector que reconoce si lo que el usuario escribe es morse o texto para así realizar la traducción correspondiente.

Para el desarrollo, me basé en el framework LinxPHP desarrollado por Javier Arias. Compañero de trabajo y amigo.

Para la lista “to do” tengo:

1) Agregar la generación de sonido que Arturo Moya me sugirió hace 4 años.
2) Crear una API para que pueda ser usado por otras aplicaciones
3) Crear la versión para móviles.

Y si me siguen dando sugerencias, la lista será aun más larga.

Gracias a todos los que hicieron que mi hobbie sea útil también para otras personas.

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

Hace algunos años, si hablábamos de dinámica en el lado del cliente, hablábamos casi exclusivamente de Flash o applets Java, pero eso cambió y sigue cambiando. Miren, sino, este gran experimento: Browser Ball

Se trata de una mezcla entre JS y Canvas para hacer rebotar una petota dentro de varias ventanas.

Si, varias ventanas. Cuando inicien Browserball, prueben generar una nueva ventana, acerquenla a la ventana padre hasta que se superpongan levemente y luego hagan rebotar la pelota. Les aseguro que se van a pasar un buen rato jugando.

Lo vi en Reddit