Categoría: Internet

Temas relacionados a TCP/IP, WEB y tecnologías afines.

Un emulador Gameboy Color escrito en JavaScript

Cuando JavaScript apareción en 1995 como parte del Netscape para permitir cierto tipo de animación dentro del bastante estático HTML de aquel entonces nadie penso que dicho lenguaje que corria únicamente dentro del navegador terminaría convirtiendose en una suerte de lingua franca de la web y permitiría llevar la interacción de la web a niveles de borrar practicamente la frontera entre el escritorio y el navegador. No hace mucho Fabrice Bellard presentó un emulador de PC, que permite entre otras cosas cargar un kernel de Linux en el navegador. Me he encontrado el día de hoy con un proyecto Open Source llamado GameBoy-Online (escrito por Grant Galitz un jóven programador de 19 años), que permite emular el GameBoy Color dentro de un navegador que soporte Canvas de HTML5.

Existe una versión de prueba publicada por el autor en su website y es alli donde he probado Tetris (que descargue desde aquí). Lo he probado tanto en Google Chrome como en Firefox 3.6.17 y funciona bastante bien, la usabilidad es la misma que se obtiene en un emulador que corra en el escritorio. Un detalle interesante es que cuando inteté correrlo en mi Nexus One, no me mostraba la opción de File (que permite cargar los juegos desde el almacenamiento local).

De todas formas un proyecto muy interesante y que podría decirse extiende un proyecto educativo anterior que Imran Nazar inició en su blog llamado "GameBoy Emulator in JavaScript and HTML5", en el cual en cada uno de sus post describía cada una de las partes del emulador. Información que resulta útil si se desea escribir algún otro tipo de emulador. O si por el contrario se desea entender el código del proyecto GameBoy-Online.

Tal vez la potencia que ha alcanzado JavaScript y HTML5 es lo que está haciendo converger todos los sistemas operativos en el browser, el primero en aparecer fue Google Chrome OS, pero ahora me he enterado que incluso la última versión de Mac OS X Lion permite el bootear el sistema operativo en un modo de sólo browser, que básicamente es lo mismo que Chrome OS. Sin embargo la cosa no queda alli, al parecer el desarrollo de aplicaciones para Windows 8 será en JavaScript y HTML5, según he encontrado en algunos forums de desarrolladores Microsoft, aquí lo que dice BitDisaster sobre el tema. Abonando además la teoría de que Microsoft abandonará .Net en favor del desarrollo en JavaScript y HTML5, ayer apareció un pequeño post en Electronista titulado "Desarrolladores critican la dependencia de Windows 8 en HTML5 y JavaScript". Por otro lado un punto de vista más moderado es el que postula ArsTechnica en un un post de ayer sobre el mismo tema que titula "Por qué Microsoft ha aterrorizado a sus desarrolladores sobre el código para Windows 8" y deja claro que Windows es aún el rey de los escritorios, pero la desesperación de Microsoft por entrar al mercado de los móviles la está obligando a tomar este camino que no por ser arriesgado, significa que el gigante de Redmond no pueda ganar mucho con este nuevo paradigma. Además recordemos que la promesa de Microsoft para Windows 8 es que el mismo sistema operativo correrá en todos los dispositivos y veo difícil que aplicaciones .Net (debido a lo pesado del runtime) puedan correr en móviles o tablets con procesadores ARM.

Mi duda es ahora que tenemos Android y iOS en los móviles, Windows en los escritorios y HTML5/JavaScript en la web, cual de estos tres caminos terminará siendo el que la mayoría de los usuarios (mercado) decidirá seguir en el largo plazo. Definitivamente cada uno de ellos tiene sus propias fortalezas y debilidades, pero como dice Connor MacLeod: "Sólo puede haber uno".

Publicado el por volkan68 7

PHP Fog ofrece 100 MB gratis para hostear tu aplicación en la nube

El día de ayer fue lanzado oficialmente a todo el público PHP Fog un PaaS (Platform as a Service) que ofrece la posibilidad de correr aplicaciones PHP en la nube, es un servicio similar Heroku que ofrece correr aplicaciones Ruby en la nube. Uno de los atractivos de PHP Fog es que permite comenzar gratuitamente, ofreciendo 100 MB de espacio de hosting, 20 MB de espacio para la DB y 15GB de tráfico, que para cualquier aplicación pequeña es más que suficiente, todo esto por un período de prueba de 6 meses. Hay servicios pagos en caso de que se desee escalar la aplicación desde $29/mensuales hasta $249/mensuales, más detalles en la sección de precios de PHP Fog.

Uno de los atractivos de PHP Fog es que permite correr populares aplicaciones PHP como WordPress, Drupal, Joomla o SugarCRM, así como también se puede elegir entre diversos framworks si deseamos construit algo por nuestra cuenta, estos por ahora son CakePHP, Shopify API, Zend Framwork y CodeIgniter, finalmente si deseamos sólo hostear código PHP existe la opción Custom App.

Actualmente el servicio cuenta con alrededor de  20,000 usuarios y parece bastante rápido al menos a nivel de control panel. He intentado crear una app con dominio propio y ellos requieren delegar los DNS a sus servidores DNS: ns1.phpfog.com, ns2.phpfog.com, ns3.phpfog.com; Sin embargo me he dado cuenta de que incluso luego de que el control panel dice que la aplicación esta activada, debido a que sus DNS no se refrescan frecuentemente no se puede acceder a la aplicación durante las primeras 2 horas.

La forma como se publican las aplicaciones es a través de la herramienta de control de versiones git, es decir se desarrolla localmente en su PC, luego usted "publica" sus cambios en el repositorio, esta aproximación es muy buena ya que permite a más de un desarrollador trabajar en una misma aplicación sin dañar el trabajo de otro. Para los que deseen un breve tutorial con un resumen de los comandos básicos para usar este software de control de versiones pueden visitar la documentación oficial en kernel.org.

UPDATE: PHPFog ha mejorado la forma de redireccionar dominios propios y lo ha documentado muy bien aquí. He levantado una aplicación de prueba que usa el dominio phpfog.cix.pe.

Publicado el por volkan68 0

Nokia ha muerto, pero nadie se lo ha dicho.

El día de hoy (27 de abril 2011), Nokia ha anunciado oficialmente que despedirá 4000 empleados a nivel global en un periodo comprendido entre hoy y finales del 2012. Además sorprendentemente Nokia ha transferido a Accenture (una compañía de desarrollo de software muy próxima a Microsoft) todo el proyecto Symbian, incluyendo a sus 3000 empleados, cuando digo transferir estoy haciendo uso correcto de la palabra, no es un error de la traducción. Nokia no ha podido vender el proyecto Symbian, nadie ha querido comprarlo, ni siquiera sus mismos empleados.

Cuando el nuevo CEO de Nokia Stephen Elop, hiciera público su comunicado interno donde comparaba la situación de la empresa con la del trabajador de una plataforma petrolera en el mar del norte en llamas que se enfrentaba ante la difícil situación de permanecer en la plataforma y morir incinerado o saltar al mar y morir congelado; finalmente la historia termina con el salto al mar de noche y el milagroso rescate posterior del trabajador. El comunicado completo puedo ser leído en Engadget. Luego de hecho público ese comunicado a inicios de febrero, todo el mundo concordaba en que Stephen Elop era brutalmente honesto, muchos decían que si los banqueros en Wall Streer hubieran actuado así, no nos encontraríamos en la actual situación. Luego vino el acuerdo con Microsoft por 1000 millones de dólares en inversiones durante los próximos cinco años a cambio de que Nokia se embarque en el proyecto Windows 7 para móviles, algunos comenzaron a ver a Elop como un caballo de troya introducido por Microsoft para ganar el control de la transnacional finlandesa, otros hablaban de una simbiosis perfecta en al cual todos ganaría. Hoy día queda claro que no es ni lo uno ni lo otro, Elop es el tradicional gerente que sólo desea presentarle números azules al directorio a cualquier precio.

Por qué Nokia está muerta, pues básicamente porque ha externalizado todo su departamento de Investigación y Desarrollo a Microsoft, que dicho sea de paso es la opción más cara de todas. La cereza en el pastel es que el market share de los teléfonos Windows 7 está cayendo y 1 de cada 2 nuevos smartphone vendido es Android y 1 de cada 4 es un iPhone, detalles en el blog de Nielsen.

Sin un departamente de Investigación y Desarrollo, que diferencia a Nokia de un fabricante chino o taiwanes cualquiera, el problema es que las plantas de producción de Nokia están en Europa y pagan salarios europeos. La reducción de personal es sólo el primer paso de un largo camino que pasa por la externalización de la producción a China, más reducciones de personal y continuas reducciones salariales de la gran mayoría de los empleados (CEO, directores y gerentes exceptuados), para finalmente terminar con la venta de la compañía a otra gran transnacional.

Publicado el por volkan68 0

Android el smartphones más usado en USA

He tenido unos días muy ocupados que me han mantenido alejado del blog, pero no podía dejar de comentar la noticia de que Android es ahora el sistema operativo de smartphones más usado en USA, tras haberle arrebatado el primer lugar a Blackberry. Todo esto según unas últimas estadísticas presentadas por comSocere del uso de plataformas móviles. Hace poco más de un mes Nielsen Wire, también daba como la plataforma más usada a Android, con lo que los resultados de comScore sólo confirman una tendencia.

No cambió la tendencia el hecho que Apple ahora venda también su iPhone en Verizon, alli tiene un competidor de gama alta llamado HTC Thunderbolt que se vende mucho mejor que los iPhones en los distribuidores de Verizon, según un reporte de la firma consultora BTIG que ha sido divulgado por el portal de noticias AndroidCentral.

El cuadro que resume el cambio en la composición del mercado de smartphones en USA entre noviembre 2010 y febrero 2011 es este:

comSocre Marzo 2011

El papel que está haciendo Microsoft es realmente malo, luego de haber gastado cientos de millones de dólares en el lanzamiento de Windows 7 para móviles y el trato con Nokia que le costo mil millones de dólares, para perder 1.3% del mercado en tres meses es un indicativo que Microsoft es tan malo tratando de entrar a las plataformas móviles como lo es Google tratando de entrar al universo de las redes sociales. Otra cosa que queda claro,  aparte de la limitada visión estratégica de Steve Ballmer (actual CEO de Microsoft), es la gran visión de Eric Schmidt como CEO de Google, ya que el compró el proyecto Android en agosto del 2005 y al cabo de 5 años terminó convirtiendose en la clave del éxito en el sector de móviles para Google.

Al parecer lo que muchos analistas temían que es el hecho de que Apple sea superado por los fabricantes de equipos compatibles con Android está pasando, si Apple no hubiera comenzado a ditribuir sus teléfonos a través de la red de Verizon, tal vez en estos momentos estaríamos viendo un declive de su cuota de mercado. Pero como sucede con todo en las TIC, el efecto network tiende a favorecer al que posee la cuota de mercado más grande, haciendo esta más grande. Sucedió con la PC y Windows, con Google en el segmento de buscadores  y con Facebook en el segmento de las redes sociales. Al parecer ahora la homogenización en la plataforma de móviles ocurrirá alrededor de Android. Si tan sólo Apple hubiera sido menos obsesiva en tratar de controlar toda la plataforma (hardware/software) y hubiera permitido que existan equipos compatibles con iOS, pero queda demostrado que Steve Jobs no es tan inteligente, ni visionario como muchos creen; despues de todo es tan sólo uno más de los que vuelven a tropesar con la misma piedra.

Publicado el por volkan68 0

Frameworks Python que trabajan con App Engine

Google introdujo ya hace un par de años (es increíble como el tiempo transcurre) el servicio App Egine que permite desplegar aplicaciones web sobre la infraestructura de Google, lo cual permite escalar fácilmente las aplicaciones desarrolladas. Por el momento sólo dos leguajes son soportados por el servicio Python y Java, lo cuál tal vez ignora a la mayor de todas las comunidades PHP, pero eso es otro tema. Hoy quiero centrarme en los frameworks Python que permiten trabajar con este servicio de Google, que permite a todo desarrollador web desplegar una aplicación sobre una de las infraestructuras de red más grandes del planeta.

El primer framework sobre el quiero comentar es tipfy, este es un framework orientado a trabajar con Google App Engine, lo cual es criticado por muchos como su punto débil debido a que las aplicaciones creadas con él no pueden ser corridas independientemente. He encontrado un muy interesante post en el blog de Ian Lewis titulado "Una introducción al Framework Tipfy para AppEngine", si seguimos las instrucciones indicadas en este post podremos tener corriendo una aplicación básica en menos de diez minutos.

Otro framework que deseo mencionar es flask, que se define a sí mismo como un micro-framework para Python que permite el uso del sistema de templates Jinja2, a diferencia de tipfy, los desarrolladores de flask lo diseñaron para correr sobre múltiples servidores web, siempre y cuando estos soporten WSGI, lo que significa que podrá correr sobre Google App Engine, CherryPy o Tornado. He encontrado el post titulado "Volando con Flask y en Google App Engine" de Francisco de Souza muy útil y lleno de tips de como poner a trabajar flask en App Engine, debido a que usa como ejemplo el desarrollo de una aplicación para bloguear 100% funcional, aunque básica.

Ahora quiero comentarles sobre mi favorito, Bottle. Es el más pequeño de todos, el framework entra en un sólo archivo de 73KB. Una de sus ventajas es que al igual que flask en adición a poder funcionar en App Engine, este framwork también puede funcionar de manera independiente o dentro de otros servidores web que soporten WSGI, así que si uno es un paranoico y cree que Google puede ir fuera de servicio, este framework nos permite desplegar la aplicación en servidores propios. Aunque el sistema de templates que usa por defecto es muy simple, eso no quita que sea ultra versátil, pero si se desea algo más sofisticado este framework puede integrarse con otros sistemas de templates como mako, Jinja2 o cheetah. Un muy buen tutorial que explica como crear y desplegar una aplicación en Google App Engine lo he encontrado en el blog de Rutwick Gangurde, el post se titula "Use el framework Python Bottle con Google App Engine", del cual estoy pensando hacer una traducción porque me parece muy didáctico y ayudaría a muchos a empezar a desarrollar aplicaciones en App Engine.

Finalmente, pero no por ello menos importante, tenemos al Django-norel que es una versión de Django que puede correr en bases de datos no relacionales como es el caso del Big Table que Google usa en App Engine. Django es mucho más que un framework es casi un CMS, el único problema que le veo es su tamaño. Un buen tutorial sobre como correr las aplicaciones Django puras en Google App Engine puede encontrarse aquí.

Publicado el por volkan68 1