8 sep
2013

Vulnerabilidad al usar express.bodyParser()

Una de las grandes ventajas de la programacion es que todos los dias se aprende algo nuevo. Hace tiempo ya que uso node para la mayoria de los proyectos que inicio. Es facil, rapido y sencillo programar casi cualquier cosa. Se convirtio en mi reemplazo de php. En la mayoria de las ocasiones tambien, uso express.js un framework que permite usar de manera muy sencilla un “mini” servidor web. Te permite escuchar todo tipo de requests (GET, POST, PUT etc..), hacer las operaciones necesarias y responderlos. Una de las caracteristicas de express.js son los “middleware” que basicamente son addons de codigo configurables para que cuando se llama al servicio definido, se hagan diversar operaciones antes de que se ejecute el codigo definido en tu script. Uno de esos middleware es bodyParser() que no es mas que un wrapper para otros 3 middleware y procesa cualquier parametro pasado de tipo json, urlencoded o tambien, un file upload.

El problema viene que tambien incluye el middleware multipart() para procesar los uploads, y este a su vez, cuando recibe un request para subir un archivo, crea un archivo temporal /temp que despues no es borrado automaticamente. Esto puede causar que a la larga, el disco se llene y el servidor obviamente se caiga. Esto tambien lo hace vulnerables a ataques por que con un simple bots se puede llenar de request a un servidor para que cree millones de archivos temporales llenando la capacidad de disco del servidor. La solucion es borrar el contenido de  /temp cada vez que se termina de usar una funcion que se encarga de subir archivos y no usar bodyParser() de manera general, sino usar cada middleware necesario para cada servicio declarado. Si tenemos que parsear json, usamos json(), para urlencoded, lo mismo y solo si necesitamos subir archivos, usamos multipart(), con la precaucion de borrar el contenido de /temp al terminar la ejecucion del servicio.

Tambien, gracias al open source, alguien hizo un fork y existe mutiparty, un reemplazo de multipart como middleware que no tiene este problema de crear los archivos temporales en el upload y es muy facil de integrar.

Referncias:

Link original: http://andrewkelley.me/post/do-not-use-bodyparser-with-express-js.html

Stackoverflow issue: http://stackoverflow.com/questions/14612143/node-js-express-framework-security-issues

8 sep
2013

Review: 7 meses con DigitalOcean

Creo que ya es momento de relatar mi experiencia despues de ser mas de 7 meses cliente de Digital Ocean como proveedor de cloud hosting.

Salto de fe

Voy a reconocer que pasarme a Digital Ocean fue un salto de fe. Obviamente esta decision fue muy basada en el precio. El tener un VPS con discos SSD por $5 USD era algo muy bueno para ser cierto, pero muy tentador al mismo tiempo. Nunca fui muy fan de los cloud hosting, los VPS siempre me gustaron pero despues de probar muchooos proveedores, dedicados y VPS, uno de los pocos “cloud” que me convencieron fueron linode, aunque era mucho mas caro. Mis primeros pasos en el servicio fue timido, fui probando, haciendo, y hasta automatizando varios procesos con su API. Al final, el precio y el rendimientos eran ideales para mis necesidades, asi que me pase definitvamente.

On Demand para todo

Una de las grandes caracteristicas del servicio, es que se pueden agrandar y achicar los servidores con un solo click, cosa que le da mucha flexibilidad dependiendo tus necesidades. La unica sorpres es que el resize es tipo “fast”  con lo cual, se agranda la RAM pero no el espacio de disco. Si queres agrandar todo, inclusive el disco, hay que apagar el VPS, hacer un snapshot, destruir el VPS y volverlo a crear con este snapshot. Usualmente esto no es un problema, pero esta el siguiente problema:

1) las ip’s son entregadas dinamicamente, asi que no esta garantizado que en la destruccion/creacion del VPS conserves la IP. Esto es un gran problema si no tenes un load balancer en el frontend para manejar los request (depender de la propagacion del DNS puede tener consecuencias en el SEO y perdida de visitas)

2) la creacion de snapshot en el 80% de las veces es echa perfectamente y en menos de media hora. Pero cuando no, el sistema deja de responder  y queda en una queue que la unica forma de destrabarlo es con un request a soporte y volverlo a hacer, esperando que termine, pero tambien, produce un downtime importante.

Bugs pero con un muy buen soporte

Me encontre con varios problemas del servicio, no con el rendimiento, sino mas que nada con funciones como el snapshot, la distribucion de las mismas imagenes en todas las regiones etc.. estas cosas a veces se bugean y quedan en una queue interminable, lo que amplia el downtime de manera exponencial. La unica forma de solucionar esto, es con un ticket de soporte. Lo bueno es que el soporte es muy rapido y effectivo, por lo que cualquier problema, es normalmente solucionado en menos de 10 minutos (aunque la solucion a veces es la frustrante reiteracion de la misma accion esperando que no sufras el mismo problema otra vez)

No internal lan, la ironia de un servicio cloud

Puede ser una estupidez, pero es fundamental cuando pensas escalar una app a largo plazo. Si o si, si pensas que tu trafico va a crecer de manera exponencial, aunque puedas hacer crecer el VPS a 16 cores, vas a tener que poner la DB en un servidor, el web server en otro y los assets en otro como opcional, y la comunicacion entre estos procesos, usualmente es dentro de una misma LAN para que sea seguro y rapido. Desgraciadamente esto no existe en digital ocean, por lo tanto la comunicacion tiene que pasar via internet. Esto no solo es un gasto extra en transferencias, sino un setup mas complicado e inseguro, como por ejemplo teniendo que poner una base datos escuchando en una interfaz publica y encriptandola, sea por una metodo nativo (como puede ser mysql SSL) o una VPN

Una IP x VPS

En la mayoria de los casos esto no es un problema, ya que si necesitas mas IP’s por tener que usar Apache y varios SSL, estas obligado a poner un SSL por VPS. Es una cuestion importante a tener en cuenta al planear el set up de tu plataforma.

3 locaciones, con 4 data centers a elegir

Hoy dia ofrecen locaciones en SF, NY y amsterdam, bastante flexible y anunciaron expandirse a brazil y asia tambien.

Conclusion

Esto no es un “simple” servicio cloud, aunque lo parece. Tiene mucho potencial y es altamente flexible, pero debe ser echo por gente experimentada en la instalacion de arquitecturas de servidores, ya que requiere de configuracion  y de tecnicas extras de contencion a la hora de escalar para palear los errores en la creacion de snapshots e instanciacion de servidores que no esta garantizado de que funcione siempre. Mas alla de eso, es un servicio de excelente calidad, con un soporte de los mejores que he experimentado, ademas con el precio mas economico del mercado. Puede que no sea adaptable a todo proyecto, pero creo que se adapta las necesidades de la mayoria de los usuarios. Un servicio ideal para devs tambien, que inician desarrollando su app de forma timida y requieren a largo plazo ampliar su capacidad de procesamiento sin poner grandes cantidades de dinero al empezar.

Link: DigitalOcean

 

7 sep
2013

HAproxy con SSL

Que puedo decir, me ENCANTA HAproxy :P creo que es una genialidad que existe un load balancer que es muy facil de configurar y que simplemente funciona !. Las ultimas versiones de desarrollo, son estables, y ademas, agregaron soporte para SSL. Para mi este soporte fue fundamental para que pudiera desarrollar un proyecto especifico. Tengo que decir que fue tan importante, que ahorre casi $100 USD de inversion inicial en servidores, por podes escoger un provider cloud y mas barato, y podes redirigir el trafico a una instancia VPS que puedo agrandar y achicar sin problemas.

En fin, una mini nota con un pequenio tuto de como agregar soporte SSL:

1) Instalar una version dev de HAproxy que sea mayor a 1.5-dev18

2) usar una config files como por ejemplo:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
global
maxconn 4096
nbproc 1
#debug
daemon
log 127.0.0.1 local0

defaults
mode http
option httplog
log global

frontend unsecured *:80
timeout client 86400000
mode http
option httpclose
option forwardfor #forward’s clients IP to app
default_backend www_backend

frontend secured
timeout client 86400000
mode http
option httpclose
option forwardfor
bind 0.0.0.0:443 ssl crt /home/ssl/www.yourdomain.com.pem
default_backend www_backend

backend www_backend
mode http
balance roundrobin
cookie SERVERID insert indirect nocache
option forwardfor
timeout server 30000
timeout connect 4000
server server1 localhost:8001 cookie server1 weight 1 maxconn 1024 check

la parte mas importante de esta config, es la construccion del archivo PEM, que basicamente contiene:

yourdomain.key

yourdomain.crt

CA.crt

en ese orden especifico. Osea, debe incluirse el contenido de esos 3 archivos (2 generados, el key y el crt) y el CA (bajado del proveedor de su certificado SSL) en el PEM, en este orden.

Y listo, con eso, podemos entrar a nuestra URL con HTTPS y HTTP y todo va a ser redirigido a nuestro backend server.

6 sep
2013

OpenFL, el game engine multiplataforma basado en Haxe


Una de las preguntas mas comunes dentro de los mas nuevos devs que quieren iniciarse en el desarrollo de VJ es “Que Engine/framework/plataforma uso?” Una pregunta bastante amplia que es muy subjetiva a que tipo de juego y a que plataformas se planea ejecutar dicho juego. Personalmente todos los juegos o aplicaciones altamente interactivas que hice fueron escritas en flash (as3), un lenguaje me resulto muy versatil y con una curva de aprendizaje muy sencilla, mas para mi, que venia con una practica en java y son lenguajes practicamente iguales en muchos sentidos. La mayoria conoce los problemas de flash, y mas en juegos, adobe hizo todo lo que pudo para matar a su propia gallina de los huevos de oro. Asi, se podria decir que OpenFL es un sucesor natural de flash, con agregados interesantes, totalmente open source y ademas, bastante usable si se tiene la suficiente paciencia.

The good

Las partes lindas de OpenFL son las siguientes:

*Multiplataforma: podes compilar con un click a Windows, Mac, iOS, android, flash y html5. la mayoria de las cosas funcionan con el mismo codigo en todas las plataformas, aunque la mas “buggeada” sea la build de HTML5 por las implementaciones pesimas que tienen los navegadores y sumado a la pesima conversion que hace haxe para codigo en JS. De cualquier manera tiene soporte de macros, con lo que la deteccion de cada plataforma en ejecutar uno y otro codigo es muy sencilla.

*Sintaxis muy parecida a AS3: OpenFL esta basado en haxe, un lenguaje muy parecido a AS3, tiene alguna diferencias como loops, los nombres de clases inician con mayuscula etc.. pero lo demas, es casi igual. Plus, en la mayoria de las ocasiones, se usan los mismos packages que en flash (tipo flash.display.sprite) con diferencias en sus objetos, pero con una documentacion de la API se soluciona bastante facil.

*Rendimiento aceptable: No es el santo grial, menos cuando el target es mobile, pero teniendole paciencia, tiene un rendimiento mas que aceptable. Sufre de mismos o mas problemas que flash en cuanto a rendimiento, no se pueden usar muchas clases de Sprite que son las mas complejas, es mejor utilizar tecnicas de renderizado en Bitmap como hace flixel por ejemplo.

*Framework mas conocidos listos para usar: Hay versiones de flixel, haxepunk y Box2D para fisica, por lo que la integracion es muy simple, y si tenias experiencia en estos en flash, es muy facil adaptar cualquier codigo a haxe.

*JNI/ExternalInterface/iOS bridge: Con paciencia, ya que hay que probar mucho, pero es totalmente posible, se pueden ejecutar funciones compiladas en .jar o echas en C# o en un SWF o usando la ExternalInterface desde flash con javascripts, asi que la integracion de codigo nativo con OpenFL es totalmente posible y transparente. Esto tambien hace posible la integracion de 3dr party libraries tipo admob, mochiads etc..

*Comunidad muy activa: hay una comunidad muy activa detras de esto, son muy proclives a ayudar tambien, tanto en el foro como en el IRC

The Bad

*Poca documentacion y clara: Hay que reconocer que para el que recien se inicia, es muy dificil empezar con OpenFL. Hay poca documentacion, desactualizada (ya que OpenFL es una evolucion del anterior framework NME, del cual se cambiaron muchas cosas) Y muchas cosas, hasta escenciales, se deben solucionar con mucha prueba y error.

*Frameworks no estan 100% usables para todo tipo de proyecto: Flixel es genial, haxepunk tambien, pero me di cuenta que la adaptacion a las diferentes pantallas, mas que nadas de mobile, no esta lista de ninguna manera. Me encontre con varios problemas de adaptacion de la “vista” de los elementos que requiria una refactorizacion muy grande del engine en ocasiones especificas. Son engines ideales para un proyecto del tipo pixel, pero si necesitas calidad, nitidez, y que sea pixel perfect, es mejor usar OpenFL pelado, teniendo cuidado de no abusar de los resources.

*No es totalmente estable, aun menos con con 3dr party libraries: Hay varios errores como la -ObjC flag en el compiler de Xcode cuando se incluye la libreria de admob que se arrastra desde NME. Hoy dia integrar 3dr party libraries es fundamental para cualquier proyecto, desde una integracion de login como FB, a un programa de Ads. Esto normalmente requiere de muchas horas y hasta dias de desarrollo e investigacion, sin una garantia real de que a la larga funcione.

Conclusion

No voy a mentir, existen otras opciones, hasta quien dice, por ahi mejores, como Starling, Marmalade y por que no, hasta Unity. Cualquiera es valida, y aunque OpenFL tiene mucho camino por delante y muchos errores que resolver, creo que es una plataforma que, con suficiente paciencia, esta lista para un proyecto en produccion. Y ahi esta la clave, la paciencia es muy importante al usar OpenFL. Hoy yo tengo 2 proyectos 2D, usando OpenFL, y no estoy descontento con como van las cosas. Reconozco que por muchos momentos es frustrante, pero hay que reconocer, que es normal en la vida de cualquier dev que apunte a hacer un juego multiplataforma.

Links Utiles:

OpenFL documentacion: http://www.openfl.org/developer/documentation/

Viejo API doc (mas que nada para tener todas las flash.*  packages explicados mas ampliamente que la actual documentacion) : http://www.openfl.org/api/

HaxeFlixel: http://www.haxeflixel.com

HaxePunk: http://www.haxepunk.com

FlashDevelop con soporte para OpenFL: http://www.flashdevelop.org/community/viewtopic.php?f=9&t=3529

 

1 dic
2012

Configuracion de HAproxy para socket.io y apache/nginx

Ultimamente me encontre en la necesidad de crear una infraestructura para una aplicacion en la que estoy trabajando, que involucra varias tecnologias, entre ellas, socket.io y un web server (en mi entorno de desarrollo era apache, en el de produccion, era nginx), mas que nada por que debia mantener un esquema preciso de accesos y ademas, podes asegurar escalabilidad (ya se que existe el cloud, amazon, etc.. pero yo sigo usando dedicados comunes y corrientes :P ). Voy a pasarles una config muy util, que me tomo unos dias construir (mas que nada por mi 0 experiencia en HAproxy y que sinceramente, no soy un sysadmin, aunque me las arreglo ;) .

Que es HAproxy?

HAproxy esquema

HAproxy es un load balancer , un servidor que se pone primero antes de todo los demas, y recibe las peticiones de lo usuarios y las redirige a los servidores que van a procesarlas (que pueden ser cualquier cosa, desde un web server, a una aplicacion custom (como una con nodejs), un servidor de bases de datos etc..). Normalmente se lo pone a recibir peticiones en la interfaz de red (osea, internet) al puerto 80, donde nuestros navegadores envian las peticiones por ejemplo, al requerir una pagina web. Una vez recibida la peticion, redirige la misma a los servidores que nosotros especifiquemos en la configuracion, que usualmente en una red local/intranet.

Problema y solucion

En mi caso particular, requeria de poder soportar la escalabilidad de conexiones y respuesta a pedidos de websockets (uno de los mejores protocolos de conexion persistente hoy dia en la web y soportado por socket.io para nodejs), plus, poder servir contenido estatico desde la misma url. Nginx tiene funciones de proxy, con lo que podria realizar las 2 funciones, la de servir contenido estatico y la de load balancer, pero desgraciadamente al dia de hoy, no soporta websocket. HAproxy, se plantea como una solucion ideal para esto, es mas, en la wiki de socket.io pueden encontrar una configuracion de ejemplo, con la cual, *en teoria* podrias estar redireccionando la conexion de websockets a la app escuchando a un puerto especifico y listo. El problema recae, en que debemos filtrar por dominio, y ademas, poder servir contenido estatico desde la misma url, con la configuracion de ejemplo y con diferentes pruebas, me di cuenta que versiones estables de HAproxy esto no es posible, por que hay opciones necesarias como http-server-close que son necesarias para que la app de socket.io pueda enviarle al cliente el cliente de socket.io y cierre la sesion al terminar y puedan los nuevos pedidos del cliente (que pueden ser contenido estatico, que debe ser servidor por nginx) sea ruteado correctamente.

Despues de varias consultas a la lista de mail de HAproxy, me apuntaron al siguiente articulo donde explica de manera detallada como HAproxy maneja las conexiones de websockets. En versiones estables del mismo (1.4) faltan opciones como option tunnel fundamental para que todo esto funcione de manera armoniosa (cualquier version de HAproxy 1.5-dev10 es compatible con esta configuracion, en mi caso, use la 1.5-dev15). Aqui pueden ver como me quedo la configuracion final:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
global
log 127.0.0.1 local0
log 127.0.0.1 local1 notice
#log loghost local0 info
maxconn 4096
#chroot /usr/share/haproxy
user haproxy
group haproxy
daemon
#debug
#quiet

defaults
log global
mode http
option httplog
option http-server-close
option dontlognull
option redispatch
option contstats
retries 3
backlog 10000
timeout client 25s
timeout connect 5s
timeout server 25s
timeout tunnel 3600s
timeout http-keep-alive 1s
timeout http-request 15s
timeout queue 30s
timeout tarpit 60s
option forwardfor

frontend all 0.0.0.0:80
timeout client 5000

#por default, siempre se llama al backend del webserver

default_backend www_backend

#chequeamos que la url tenga socket.io en algun lado para redirigir a la app en ese caso

acl is_soio url_dir -i socket.io

#chequeamos que el request sea para un dominio determinado

acl is_mydom hdr_dom(host) -i mydomain

#si el request es para "mydomain" y es para socket.io, lo redireccionamos al backend correspondiente

use_backend mydom_backend_ws if is_soio is_mydom

#webserver backend

backend www_backend
balance roundrobin
server server1 localhost:6060 weight 1 maxconn 1024 check

#socket.io backend

backend mydom_backend_ws

balance roundrobin

server server1 localhost:5558 weight 1 maxconn 1024 cookie server1 check

En el link original, van a encontrar que el ACL se hace chequeando las headers por indicios de un pedido de conexion a un websocket, como en mi caso no solo soporto websockets. sino todas las conexiones que pueda hacer socket.io en el caso de que el cliente no pueda usar websockets (como xhr-polling, flashsockets, etc..) preferi checkear por “socket.io” en la url del request y redireccionar todo eso a la app si es que cumple el dominio. De esa manera se pueden tener varias aplicaciones con socket.io corriendo en la misma maquina o nodo, usando solo 1 load balancer y al mismo tiempo, servir contenido estatico desde la misma url. Probe esta config con todos los protocolos, y funciono, aunque en mi caso, flashsocket no anduvo, pero *creo* que es un problema de mi version de flash en linux.

Sin mas, espero que les sea util, les ahorre mucho tiempo en crear su propia infraestructura y cualquier duda, pueden acercarse al foro a plantear sus consultas :)

22 nov
2012

Los libros llegaron a DevNod !

QUnit CookBook Español

Como una nueva seccion dentro de DevNod, inauguramos nuestra pagina de libros, donde publicaremos tanto escritos propios como traducciones de material en ingles que creamos util para la comunidad. Como primer libro, hemos traducido el CookBook de QUnit, el popular framework de unit testing. Espero que les sea de utilidad, y ante cualquier duda, como siempre, los esperamos en el foro

21 nov
2012

Ingress: toma de contacto

Ingress Logo

No debería hacer una revisión de un juego en este lugar de la net, pero no es el clásico
social game por $0.99 por lo tanto me parece importante hacer una revisión de esta
iniciativa que pretende llevar de manera masiva un gameplay con realidad aumentada.

Que es ingress?

Es un juego que esta desarrollando google, esta en una beta cerrada y su principal
característica es que utiliza realidad aumentada como ítem principal del gameplay. Para
los que no saben, realidad aumentada se llama a la técnica que utiliza objetos reales
(como lugares, piezas etc..) para crear una experiencia interactiva virtual. Si buscan en
youtube van a ver ejemplos espectaculares de realidad aumentada, que les puede
ejemplificar la implementación típica de esta técnica. En el caso de ingress, utiliza
datos y lugares reales, usando el gps de tu dispositivo móvil para desarrollar las
diferentes características del juego.

Ingress iniciando y conectando con la cuenta

Ingress iniciando y conectando con la cuenta

Ingress se basa en un escenario de invasión dimensional. Nosotros, como
privilegiados, pudimos llegar a obtener la aplicación Ingress, que nos permite convertir
nuestro smartphone en un scanner, capaz de detectar “Portales” por los cuales los
seres invasores quieren conquistar la tierra. Estos portales están compuestos de EX
(extra materia) que se encuentra en diferentes lugares y es nuestro “consumible” a la
hora de interactuar con el “otro mundo” que nos permite ver Ingress. Por lo siguiente,
nuestro objetivo, es encontrar estos portales (que deben estar en lugares donde se
muestra la escéncia de la humanidad, como monumentos, edificios emblemáticos etc..)
y “hackearlos” para protegerlos. Una vez protegidos, debemos “linkear” estos portales
entre si, para poder formar zonas de protección para los humanos, donde se van a
poder guarecer al momento de la invasión.

Mi experiencia

Ingress segunda mision

Ingress segunda mision

El domingo a la tarde recibí mi código de invitación, sorprendido, ya que no suelo tener
la suerte de entrar en betas cerradas (y menos pensé en este tipo de app). Enseguida
me dispuse a bajarla de la google play store, asociar mi cuenta de google y agregar el
código de beta que me suministraron. Es bueno aclarar que mi equipo es un Sony
W19T con android 2.3 y para el testeo procure cargar la batería al 100% y medir la
transmisión de datos que pueden ver mas adelante en el articulo. Estaba muy
emocionado de probarla, ya que me parecía un concepto muy interesante (y reconozco
que el video me había cebado bastante :p ).Empieza contándonos una introducción
sobre que se trata ingress, con una estética muy “hacker”, todo basado en texto y
gráficos simples pero acordes a la simulación de un “scanner”. Utiliza muchas voces
reales para darnos los *briefing* de la misión, ademas de las notificaciones que
suceden, muy bien logradas y hacen que te inmersas en el juego. Como iniciación,
tenemos unas 8 misiones de entrenamiento, en donde vamos a aprender todas
funciones que podemos hacer con el scanner, y que acciones debemos usar para
asegurar los portales, recolectar EX etc.. En resumen, los portales aparecen en lugares
emblemáticos para la humanidad, y para poder asegurarlos, debemos “hackearlos” de
donde obtenemos resonadores que son usados para pasarlos a nuestro lado. Cada
portal requiere de 8 resonadores, y ademas es necesario aplicarles EX a estos
resonadores para que puedan seguir manteniendo el portal. A veces estos portales son
hostiles, por que podemos dispararles un pulso XMP para neutralizarlo. Una vez echo
esto, el portal es nuestro, y tenemos las opciones de “hackearlo” una vez mas para
conseguir la “key” del portal, que nos permite después linkearlo con hasta otros 2 y
formar las “zonas de protección”. ademas, los portales pueden ser mejorados, aunque
desafortunadamente las misiones de entrenamiento no cubrían esta acción. Reconozco
que la intención de hacerlo tan inmersivo, me confundió al principio y no sabia que
todavía debía completar estas misiones de entrenamiento para estar verdaderamente
jugando :p. No voy a detallar mas las misiones por que es lo mismo que relate
anteriormente,no hay mas que eso, solamente se pueden hacer esas acciones y en un
orden preciso. Una vez terminado el entrenamiento, debemos elegir nuestro lado, si
queremos ser humanistas (defender la tierra) o iluminados (ayudar a liberar portales
para los invasores), mi complejo de héroe me llevo a elegir humanistas. Una vez
elegido el bando, debemos recoger EX y buscar portales, en mi caso, vivo en un san
clemente del tuyu, argentina, un pequeño pueblo alejado de las urbes urbanas mas
importantes, por lo que aunque tenia la esperanza de que los portales fuerN colocados
usando la data de google maps, ya que con eso saben las locaciones de iglesias y
monumentos, mi suposición fue errónea, ya que el NSI ops se encarga manualmente
de poner los portales con las fotos de los lugares enviados por los usuarios. Los EX si
son colocados automáticamente, presumo a partir de la cantidad de kms recorridos, ya
que después de 2 horas de juego y unos 3-4km recorridos, logre encontrar 4 EX que
aumentaron mis reservas en un 8%.

Algunos problemas

Ingress falla en deploy

Aca, no me deja seguir haciendo el deploy de los resonadores, tuve que reiniciarlo.

Y como todo, no es color de rosa, hay que comentar algunos problemas vividos de la
experiencia. Por lo menos en argentina, al cobertura de datos es deficiente en todo el
país, en un pueblo chiquito como el mío, se nota aun mas. cuando estaba haciendo las
misiones de entrenamiento, la transmisión de datos se trabo y no me aparecía ningún
EX cerca, por lo que tuve que cerrar y volver a abrirla para que funcione. Me paso lo
mismo las querer hacer deploy de los resonadores, la opción se quedaba deshabilitada a
pesar de que tenia el ítem. Irónicamente, google sufre en su propio producto el
problema de la fragmentación de android, ya que en mi equipo que no tiene una gran
pantalla, muchos ítems se superponen y hacen difícil su interacción (hasta botones de
acciones importantes, aunque con un poco de maña se pueden hacer igual). De
cualquier manera no hay que sentenciarlo, esta en una beta cerrada, por lo tanto, creo
que es muy probable que todo esto sea arreglado a futuro.

Consumo

Para hacerlo sencillo, en 2 horas de uso, me consumió un 80% de batería, y las
misiones de entrenamiento me consumieron como 2.5MB de datos y el buscar EX otro
tanto.
Conclusión

El echo de poder jugar a este MMO “real” me pareció genial y me engancho lo
suficiente como para seguirlo activamente. Ahora mirándolo de otro punto vista, no
estoy seguro que el concepto logre una masa critica mas allá de los hardcore gamers.
Utiliza una cantidad de recursos importantes (mas que nada batería) , y la única forma
de que un casual user lo use es que pueda encontrar portales o EX es que lo pueda
hacer al camino al trabajo o mientras que va a hacer alguna tarea, y si el celular es una
necesidad para el resto del día, desperdiciar recursos muchas veces no es una opción.
Otro problema, es la ubicación de los portales, entiendo que es una aplicación pensada
para US y europa, así que no tengo esperanza de encontrar muchos (o siquiera
alguna) pero si la revisión de los mismos es manual, no se si van a poder crear la
cantidad suficiente al ritmo de crecimiento de usuarios en diferentes zonas del mundo.
Sin mas, mas adelante, cuando avance un poco mas, veré si algo cambio o vale la
pena hacer otro articulo al respecto, de cualquier manera aplaudo la iniciativa de
innovar usando nuevas técnicas y tecnologías que están disponibles.

8 nov
2012

La industria debe madurar, no crecer

fragmentacion

voy a hacer el futil intento de en este articulo de intentar reflejar el sentimiento que tengo
en cuanto a la industria IT (y principalmente la industria web). Espero poder poner en
palabras algo que esencialmente, es un conflicto de intereses, desde el punto de vista
comercial como tambien desde el punto de vista tecnico.

Esta verdaderamente la tecnologia a nuestro servicio?

El hombre es una maquina evolutiva, su mas basico proposito es desarrollarse. Por lo
tanto, innova y crea elementos que justamente, lo ayude a cumplir esta tarea. En este
ultimo tiempo, la fragmentacion y los intereses comerciales inherentes a cualquier
actividad, llevo a que el desarrollo de un producto, sea tecnicamente difcil sin sentido. En
los albores de la informatica, los mayores problemas que tenian los programadores era la
falta de recursos (memoria, almacenamiento, procesamiento), entonces se perdian horas
optimizando la minima parte de codigo para poder lograr la ejecucion correcta de la
aplicacion. Hoy el hardware evoluciona exponencialmente, cada vez tenemos
procesadores mas rapidos, mas memoria. mas almacenamiento, y el abaratamiento casi
irrisorio del costo de estos componentes. En cambio, el desarrollo del software esta
estancado, seguimos reinventando la rueda, en un sabor diferente al que cada
programador/empresa le gusta o conviene. Muchos basan las decisiones de crear una
plataforma/producto en una decision meramente comercial, que obviamente no podemos
juzgar, por que cada uno es libre de crear lo que quiera, el problema es cuando tiene un
efecto generalista en el ecosistema. el ejemplo mas claro es internet explorer, uno de los
primeros navegadores, que a dia de hoy, nunca se ajusto a los estandares web y sufrimos
horas y horas de adaptacion en estilos y en codigo para soportarlo. tambien se ve en el
caso de los dispositivos mobiles, los navegadores y sistemas operativos recortados en
funciones, sin soporte, creados para dispositivos de bajo rendimiento, de bajo costo pero
alta distribución, impulsada por la sociedad de consumo que tenemos hoy en dia.

Con esto quiero ejemplificar que en muchas ocaciones, la tecnologia termina siendo una
traba en nuestra evolucion. en el caso de la web, perdemos mas tiempo solucionando
inconsistencias en navegadores, discutiendo apasionadamente sobre que framework/
lenguaje/lo que sea es mejor y cuando finalmente lo elegimos, nos damos cuenta que una
nueva “moda” nos obliga a modificar nuestra codebase. Deberiamos ocupar nuestro
tiempo en buscar nuevas formas de mejorar varios espectros de nuestra vida. crear
mejores formas de comunicarnos, de expresarnos, de enseñar, en resumen, una mejor
forma de vivir

No debemos perder el enfoque

Aca empieza, como dije al principio, el conflicto de intereses. Todo lo que relate
anteriormente es la realidad que vivimos, y obviamente esta lejos de ser ideal, pero al
mismo tiempo creo que es el camino natural que debemos recorrer, para crear cada vez
mejores herramienta. Lo pienso como un paralelismo a la filosofia del open source, donde
cualquiera puede crear con un mismo codigo como punto de base o inspiración, nuevas
interpretaciones para resolver el mismo problema. A pesar de que la prueba y error es el
camino natural, no debemos perder el objetivo y el enfoque principal, que es el crear
cada vez mejor tecnologia que nos permita enriquecer la experiencia del usuario.

Y que estamos haciendo para mejorar esto?

la iniciativa mas fuerte, es lo comercialmente llamado html5 (por que esto engloba JS y
acceso a API’s nativas desde JS y HTML) y no solo en el mundo exclusivamente web,
sino que la industria de los videojuegos, la movil y hasta la de CRM/empresarial esta
moviendo su codebase, por la practicidad de portear, de mantener y de expandir en
caracteristicas de manera facil y sencilla. a lo llamado html5 le falta muchisimo para
madurar y vamos a tener que soportar estas epocas de cambio, trancisiones e
inestabilidades, pero con suerte, sera la herramienta ideal para poder concentrarnos en
crear experiencias.

6 nov
2012

GitTip: la herramienta para donar dinero a usuarios de github

GitTip

GitHub se ha convertido en el lugar donde gran parte del desarrollo y la innovacion en terminos de software esta pasando hoy dia. Basicamente en GitHub se pueden encontrar repositorios de los mas variados, una gran parte open source, para todo tipo de lenguaje y plataforma (aunque javascript y web son una gran mayoria). Cualquiera con un usuario puede crear un repositorio y empezar a subir codigo con la popular herramienta de control de versiones llamada Git. Tambien pueden crear derivacion del repositorio de otro usuario con un solo click. La verdad, he encontrado de todo en GitHub, cosas que me han ahorrado muchisimo tiempo, y a uno verdaderamente le gustaria poder darle las gracias a ese usuario de alguna manera “material”. Con ese objetivo, se creo GitTip, un sistema muy facil, y abierto para donar dinero a usuarios que con sus contribuciones, han mejorado de alguna manera el mundo :)

Como funciona GitTip?

A diferencia de otros sistemas de donacion, como los clasicos botones de paypal que vemos en muchas webs y projectos open source, GitTip trabaja sobre una estructura de pagos recurrentes. Osea, pequeñas donaciones semanales que se acreditan cada jueves. GitTip estipula un limite de $24 USD por semana y por persona que se puede donar, con un costo de 0.39 USD + 3.9% de lo que quieras depositar en tu cuenta, como cargo por las transacciones de tarjetas de credito, hosting etc.. Tambien el monto minimo que se puede depositar en la cuenta, es de 10 USD, para minizar estos gastos antes mencionados. Por lo tanto, podemos cargar nuestra cuenta con, como minimo $10 USD e instruir al sistema que le done $3 USD a X usuario, y asi, cada jueves ese usuario recibira $3 USD en su cuenta hasta que se acabe el dinero. Cabe aclarar que todas las donaciones son anonimas, el beneficiario no sabe de quien es el dinero, y tambien, son todas publicas.

Aquellos que reciben el dinero, los beneficiarios, pueden configurar una cuenta de banco (desgraciadamente solo cuentas en USA son soportadas) para que sea depositado el dinero automaticamente cada semana. En caso de beneficiarios internacionales, el proceso se hace manualmente, mediante cheques, asi que es un poco mas complicado.

Por que confiar en GitTip

La mejor razon de confiar para confiar, es que es la primera compania abierta (open company), que basicamente se rige por 3 reglas basicas:

  1. Maximizar la transparencia: Una compania abierta comparte toda su informacion y toda su propiedad intelectual es libre de uso y vista por todos. Todo el software que sea escrito para la compania es open source. La unica informacion que no es publicamente compartida, es aquella que pueda perjudicar o violar la privacidad de sus usuarios, y su informacion personal
  2. No hay empleados: Los empleados de esta empresa no reciben ninguna salario ni beneficio por trabajar en ella, la unica diferencia con otros usuarios, es su accesso a informacion sensible como privilegios en servidores, repositorios, etc.. La compania solo debe contratar a la minima cantidad de personas para manteneral operativa en el caso de ser necesario.
  3. Debe cobrar lo menos posible: Como el objetivo no es generar ganancias, debe cobrar lo minimo indispensable para poder cubrir cualquier gasto operativo.
Y ahi lo tienen, los animo a que si en algun momento quieren darle las “gracias” a alguien en alguna forma material, sin ningun tipo de ataduras, piensen en GitTip como una plataforma segura y viable para estos casos. Como bien dice el sitio, un kickstarter para personas, no para projectos.

 

6 nov
2012

Mentoring gratis sobre desarrollo de videojuegos por Heavy Boat

HeavyBoat Header

Esto es algo que no se ve todos los dias (bah, ningun dia :P ), por lo tanto merece darle una cobertura como corresponde. Los chicos de Heavy Boat vas a abrir un taller de mentoring, totalmente gratuito, para interesados en trabajar o emprender en la industria de los videjuegos. El mentoring basicamente va a consistir en crear un videojuego con un grupo de trabajo armado por los chicos de HB, gestando sus propias ideas pero bajo la constante guia y supervision de los profesionales que componen este estudio.

Que es HeavyBoat, cuando y como puedo participar?

HeavyBoat es un estudio de desarrollo de videojuegos ubicado en la Ciudad de Buenos Aires, argentina, que desarrollan juegos casuales para importantes marcas como cartoon network, warner, etc.. desde hace mas de 3 años. Tienen tiempo hasta el 9 de noviembre para enviar un mail  mentoring@heavyboat.com contando por que queres participar de este programa y que lugar te gustaria ocupar (programador, game designer, artista etc..), con el unico requerimiento de tener conocimientos previos sobre el area que quieras ocupar en el grupo de trabajo.

Pueden ver mas informacion en este hilo en duval.vg

 

Sigueme !

Follow Me! Follow Me! Follow Me!