¿Eres desarrollador web y estás a punto de comenzar un proyecto nuevo? ¿Te sientes frustrado porque es complicadísimo de manipular el javascript del proyecto en el que trabajas, o simplemente quieres estar al día en cómo se está moviendo el desarrollo Javascript? Este post puede resultarte interesante.

Tu Backend debe ser sí o sí un API, de preferencia REST

Si hablamos de Backend existentes, rápidamente escucharemos mencionar a los pesadísimos Webservices y su XML redundante, en el mundo corporate por todos lados veremos páginas Java generando JSP que a su vez arrojan el HTML, tenemos PHPs produciendo HTML, el punto es, pocos proyectos tienen un API propia, eso pareciera ser algo sólo para los grandes como Twitter, Facebook o Google Maps.

Las cosas han cambiado, actualmente tu Backend servirá para producir HTML que será visto en PCs, y probablemente tu proyecto tendrá versiones móviles, apps para televisores y claro, para el refrigerador. Si tu proyecto inicia teniendo como base de toda interacción un API, tu aplicación naturalmente estará lista para después tener una versión móvil, una app para el televisor o para algún cepillo dental con display que los japoneses pronto inventarán.

Si quieres mas información acerca de las REST API, google es tu amigo, en este artículo no pretendo entrar a detalle en aspectos técnicos de cómo hacer las cosas, nos enfocaremos en exponer los conceptos más importantes que se están moviendo hoy en día.

No vuelvas a producir HTML en tu BackEnd, sea la tecnología que sea, arroja sólo JSON y más JSON, así tendrás un Backend elegante, práctico y eficiente, además de versátil. Que sean tus diferentes clientes los que trabajen gracias a tu API, así es, leiste bien: HTML/Javascript será ahora tu cliente y de eso hablaremos en el siguiente punto.

Javascript debe ser el puto amo de tu FrontEnd

Probablemente estás trabajando en algún proyecto donde Javascript es sí o sí el nuevo jefe de jefes en tu Frontend (no lo descarto en el Backend), y seguramente algún Framework acompaña a tu código (jQuery, Dojo, MooTools, Backbone.js), y de eso quiero hablar. Mencionar al "mejor" Framework de Javascript es imposible, cada uno presume de serlo y algunos no necesariamente están peleados, por el contrario son compatibles y el uno necesita del otro.



He tenido la oportunidad de trabajar con todos los que menciono, describiré a cada uno:

• jQuery junto con jQuery UI es una interesante alternativa para enriquecer el DOM.
  
• Dojo es el Framework para el mundo corporate, intenta abarcar todo, components UI, utilerías, charts, lo que se te ocurra, pero sin ser en ninguna de esas aéreas el mejor (el que mucho abarca...).
  
• MooTools es compacto y el que más se preocupa por emular conceptos importantes en la OOP, como la herencia.
  
• Backbone.js, es algo cercano a un MVC tradicional, es flexible y a mi gusto se puede producir código muy elegante utilizándolo. No está peleado con FW como jQuery o MooTools pues tienen enfoques distintos.
  
• La lista de frameworks es grande, sólo mencioné algunos de los que he utilizado recientemente.
  

Lo que es un hecho es que todos los Frameworks actuales tienen utilerías para leer contenido AJAX, y la mayoría interpreta JSON sin problemas, y es aquí, en este punto, donde generamos la integración e interacción con nuestro API. Tendremos archivos HTML y Javascript que consumen nuestro API (como hacemos al consumir APIs de terceros) y estaremos preparados para cambiar nuestra app de plataforma con un esfuerzo mucho menor al requerido sin tener una API.

Si me preguntan por mi combinación favorita para comenzar un proyecto de FrontEnd, yo elegiría jQuery + Twitter Bootstrap(o en su defecto jQuery UI) junto con Backbone.js.

Cómo empezar: recursos disponibles

En este punto ya tienes una idea de cómo deben ser los nuevos Backends, un panorama de cuál puede ser la base de tu FrontEnd, pero tal vez aun tienes muchas dudas referentes a cómo empezar, por dónde debes iniciar. Es complicado incluir las respuestas a eso en un sólo post, sin embargo lo que sí puedo hacer es referenciarte a puntos de partida para tu nuevo proyecto HTML / Javascript. Mencionaré algunos de los recursos de hoy en día:

• HTML5 Boilerplate, es un template listo para que utilices HTML5 sin tener tantos problemas de compatibilidad. No es una solución perfecta, ni resuelve todos los problemas de compatibilidad, pero sin duda hace más ameno el desarrollo crossbrowser. Incluye también scripts ANT para minificar código, compactar imágenes entre otras tareas.
  
  
  
  
• Twitter Bootstrap, es un proyecto interesante de twitter que te permite enfocarte más en lógica de negocio y dejar de lado tareas comunes, como ventanas, layouts y botones, entre otras utilerías.
  
• Chrome - Developer Tools, es para mí la mejor herramienta para debuguear en Javascript, explorar el DOM, la actividad de la red, entre otras.
  
• Mi post tiene una clara inclinación a temas relacionados directamente con la programación, para temas como el CSS, el post de Neo es muy bueno, así como el de Freddie, que es un enfoque más general de como se están moviendo las cosas.
  

Sé que probablemente quedan muchas dudas, respecto a los Frameworks mencionados, así como de los conceptos platicados, respuestas que me resultaría difícil explicar sin extenderme a una gran pared de texto. En base a sus inquietudes principales, podría preparar algún otro artículo, enfocado mas a un "how to" en específico. El objetivo de este primer post, es mover un poco el paradigma (si es que aplica) de cómo en algunos casos se sigue trabajando. Si por ahí ya te entró la inquietud de leer más acerca de REST, probar otros Frameworks de JS, leer más acerca de Html5boilerplate o Twitter Bootstrap, creo que será la mejor ganancia de este tema.

Todavía hay mucho futuro en el mundo de los videojuegos Flash, muchas cosas que aprender y muchas cosas por hacer. Gente como Macadamia de Perú, Puelo de Argentina y Lartar de Chile han compartido con nosotros sus conocimientos sobre el tema.
Esta vez, nuevamente en exclusiva para Cristalab, el español Javier Lazaro comparte con nosotros sus experiencias en el área.

Entrevista a Javier Lazaro

Cuéntanos sobre ti, tu nombre, edad y dónde te encuentras.

Soy Javier Lazaro, 37 Años, Valencia (España).

¿Qué haces en tu tiempo libre?

Suelo jugar juegos (flash, sobre todo), y me gusta leer. También me gusta el Animé y ver películas y series de ciencia ficción y terror. Me gusta ir a la piscina de vez en cuando, ya que paso demasiado tiempo encerrado y sentado, lo que no es bueno para mantener la línea...

¿Qué haces profesionalmente? ¿Tienes estudios formales?

Tengo dos titulaciones: Bellas Artes y Diseño Industrial. Actualmente dirijo la web ClockworkMonster.com, hago juegos en Flash y doy clases de diseño de juegos Flash en la Escuela Superior de Arte y Tecnología de Valencia. De vez en cuando hago de Sponsor (si veo algún juego que me guste y tengo fondos), y he hecho algunos advergames para Grayling.

¿Cómo nació tu idea de crear juegos?

En 2007 me pasé un año trabajando en telemarketing, vendiendo ADSL por teléfono. No me gustaba el trabajo, así que empecé a plantearme otras opciones. En principio me plantee algo más típico, diseñar páginas web... Hasta que oí hablar de Kongregate, MochiAds y FlashGameLicense. Descubrí que había posibilidades en un campo mucho más atractivo, como es el del diseño de videojuegos.

Así que me puse a estudiar AS2 y a aprender a animar con Flash. Compré algunos libros, descubrí el blog de Emanuele Feronato (Gracias Emanuele, por esos tutoriales) y en 2008 ya tenía mi primer juego. Conseguí vender licencias de mis 2 primeros juegos a Ugoplayer (Gracias, Mel. Si no hubiera sido por tí probablemente estaría vendiendo ADSL ahora), y eso me animó a dedicarme al 100% al diseño de juegos.

¿Cuáles fueron tus primeros juegos?

Siris y Mk5 fueron los primeros, ambos basados en tutoriales de Emanuele Feronato. Casi me da vergüenza enseñarlos ahora...

¿Cómo evolucionaron tus conocimientos?

Tuve que aprender de cero, de forma autodidacta.
Empecé con ActionScript 2, ya que era más sencillo y había muchos más tutoriales online y libros publicados en ese momento de AS3, y fuí aprendiendo sobre la marcha. En cada juego intentaba aprender cosas nuevas y las aplicaba a las mecánicas del juego.

Hace un año empecé la transición a AS3, una vez más a base de libros y tutoriales. Me costó, ya que había adquirido malos hábitos con el AS2. También tuve que aprender a utilizar el Photoshop (para editar imágenes y fondos), el SoundBooth (para editar sonidos) y por supuesto Flash. Y cuando probé a crear mi propio portal, me tocó aprender algo de CSS, HTML, MySQL, SEO y diseño de páginas web...

¿Qué problemas surgieron en el camino y cómo los superaste?

Los principales problemas fueron económicos. Con 34 años, sin trabajo, y con una hija y una hipoteca no es fácil meterse en este mundo empezando de cero. El primer año los ingresos fueron muy bajos, y me costó mucho convencer a mi familia de que valía la pena seguir intentándolo. Estuve a punto de dejarlo.

¿Desde donde trabajas? cuéntanos sobre tu equipo de trabajo y las herramientas que utilizas.

Trabajo desde casa (Soy un "Bedroom coder"), con un pc "normalito" (intel T7400, monitor 17"). Trabajo con Adobe Flash directamente, y Photoshop para algunos retoques gráficos.

¿Cuánto tiempo dedicas diariamente al tema?

7-8 horas, dependiendo del día. Aunque en estos momentos estoy bastante disperso al dedicarme a dar clases, mantener el portal, sponsorizar juegos y hacer juegos propios cuando tengo un rato. Al final mis juegos se están quedando algo estancados.

¿Qué tanto tiempo tardas en crear un juego?

Me cuesta mucho terminar los juegos, sobre todo en la fase final. Siempre quiero pulir detallitos o gameplay, y que el acabado sea profesional. Si me dedico al 100% al desarrollo de un juego, suelo tardar de 4 a 8 semanas, dependiendo de lo complejo que sea el juego. Mi ventaja es que yo hago diseño, gráficos y código, con lo que tengo muy claro lo que quiero hacer y cómo integrarlo. Pero es también una desventaja, ya que no soy especialista en programación ni en gráficos, lo que supone trabajar más despacio.

¿Cómo promocionas tus juegos?

3 medios: Newgrounds y Kongregate funcionan muy bien si el juego tiene éxito y tiene muchos votos. Siempre hay publishers al tanto de las novedades en estos portales.
El problema es que otros portales pueden "fusilar" tu juego mientras tiene pocos votos, hundiéndolo antes de que pueda aparecer en primera página. Ya me ha pasado varias veces.

Esta misma semana, con el Nightmare Runner en Newgrounds: Obtuve una puntuación de 3,5 mientras estaba en "under Judgement", pero afortunadamente el personal de Newgrounds se fijó en el juego y lo puso en primera página. Ahora está en 3,85 puntos, por encima de algunos de los juegos que fueron "Daily Picks" ese día (alguno ha bajado notablemente su puntuación...).

Conclusión: Búscate muchos amigos que te voten cuando subas tu juego a Newgrounds o Kongregate.

También vía Flashgamedistribution, Playtomic (enlace con mi referencia) y el canal de distribución de MochiAds, sencillos de usar.

Además, tengo una lista de emails y webs a los que enviar los juegos, que he ido recogiendo durante estos años.

¿Cómo monetizas tus juegos?

Actualmente sponsorizo mis propios juegos, con lo que mis fuentes de ingresos son:

1. Mi portal www.clockworkmonster.com.
   
2. Ingame Ads (MochiAds y CPMStar. Tengo que probar Intergi).
   
3. Licencias no exclusivas de mis juegos. Para esto Flashgamelicense es muy útil.
   

¿De cuál de tus juegos te sientes más orgulloso y porqué?

Nightmare Runner. Ha sido el juego en el que más he trabajado, cuidando mucho la estética y buscando crear ambiente mediante la música y los fondos. Por primera vez he utilizado Playtomic y el "Game Tracker" de FGL para obtener datos precisos del juego, y esto me ha permitido pulir muchos detalles y mejorar el resultado final. Se me han quedado algunas cosas en el tintero, pero las iré añadiendo en una segunda parte.

¿Cuál de tus juegos ha generado más dinero y cómo explicarías su éxito?

Sin duda, 21 Balloons, con el que he ganado alrededor de 15.000 euros (puede que mas, ya que no puedo determinar cuánto tráfico ha enviado a mi portal y no tengo todos los datos de MochiAds).

Es una historia bastante curiosa: Probé a hacer un juego para niños, pero me quedé bloqueado. No sabía cómo terminarlo, y pensaba que sería un fracaso. De hecho, acabé tan harto del juego y de los ositos que abandoné el proyecto e hice el juego Love Overdose reutilizando gráficos. Love Overdose se publicó antes de San Valentín, y fue bastante exitoso.

Así que decidí terminar el juego. Lo puse a subasta, pero obtuve unas ofertas extremadamente bajas. La más alta era una exclusiva sin Ads por 200$, lo que me hizo plantearme seriamente publicar el juego bajo la marca clockworkmonster y poner el portal en marcha de forma seria. Tenía otro juego, Critical Mass, que tampoco obtenía buenas ofertas (tampoco era un gran juego, lo reconozco), y el Love Overdose: tres juegos para promover mi portal. Decidí arriesgarme y probar.

21 Balloons fue un desastre. Se publicó en pocos portales. Razón: Me pasé poniendo anuncios. Estaba experimentando con los anuncios, para ver cómo podía maximizar beneficios, y le puse varios, ya que daba por sentado que el juego no iba a funcionar bien. Abusé mucho, y los portales se negaron a publicarlo. Solo lo publicaron unos 300 portales, la mayoría portales pequeños con scripts alimentados estomáticamente por el feed de MochiAds (Consejo: No abuses de los anuncios o puedes matar tu juego).
Pero entonces me tocó la lotería: El juego se publicó en MindJolt, y fué un éxito. Varios millones de plays, mostrando varios anuncios por sesión con un ECPM muy alto... hasta que MindJolt empezó a utilizar su propio sistema de publicidad y tuve que eliminar mis anuncios y poner los suyos, a comisión. Mis ingresos bajaron considerablemente.
El juego ya ha alcanzado los 12,5 millones de plays y he vendido varias licencias no exclusivas, e incluso una versión mejorada (Night Balloons). Y pensar que estuve a punto de no terminarlo...

¿Cuántas veces han sido jugados tus juegos más populares y cuánto dinero han generado?

Un poco complicado de responder, ya que CPMStar sólo me da los informes de un año y MochiAds también da informes de un período muy reducido. Sólo tengo informes exactos de mi portal. Cometí el error de no archivar mis ingresos periódicamente, y ahora sólo puedo hacer estimaciones. Además, hasta finales de 2009 mis ingresos fueron muy bajos.

Algunos datos:

• Mi portal ha generado unos 35.000 euros hasta la fecha.
  
• Juegos más jugados:
  • 21 Balloons -> 12,5 millones de veces.
    
  • Savanna Blocks -> 8 Millones de veces.
    
  • Night Balloons -> 5,3 millones de veces (Version mejorada del 21 Balloons hecha para Frosmo).
    
  • Love Overdose -> 5 millones de veces.
    
  • Mk5 WorkBot -> 4,3 millones de veces (Su diseño me dio muy buenos resultados con la publicidad)
    
  
  

¿Cuáles son tus objetivos a largo plazo, continuarás creando juegos?

Esa es mi idea. Seguir haciendo juegos y probar suerte con los juegos para Android e IPhone.
Me estoy planteando seriamente el trabajar en equipo, aunque me cuesta un poco ya que no tuve muy buenas experiencias en mi primer año. Pero pude trabajar con Bogdan Ene, y trabajar con un profesional me hizo planteármelo. La cuestión es encontrar la persona adecuada con la que puedas compartir ideas y crear juegos interesantes.

¿Algún consejo para los que vamos comenzando?

La competencia es muy dura, ya no vale lo de hacer muchos juegos malos rápido como ocurría hace 4 años. Ahora hay que apostar por la calidad, antes que por la cantidad. Hay que cuidar los detalles, los jugadores son muy exigentes. Pero también hay que cuidar la presentación. Un buen icono puede hacer maravillas.

¡Cuidado con la publicidad! Puedes matar un juego abusando de los anuncios. Si usas mas de uno, hazlo con elegancia. Distrae al jugador, que no sea evidente que le estas clavando un anuncio para sacar dinero. Integra los anuncios en el diseño, y nunca hagas esperar el jugador innecesariamente.
Piensa a largo plazo. No crees un juego, crea una marca. Así podrás crear secuelas, reusando código y gráficos, y te beneficiarás del valor de la marca, que se añadirá al del juego.

Muchísimas gracias Javier, muy inspirador todo lo que nos has contado

Valencia, 22 de Mayo de 2012.

Internet Explorer, tras más de una decada, cae al segundo lugar superado por Google Chrome, reporta Memeburn. Chrome ha sido clave en la estrategia de Google de empujar HTML5, Javascript y las nuevas tecnologías que hicieron viables las aplicaciones web.

Chrome inició comiendose el market share de Opera y Firefox, pero IE, a pesar de sus innovaciones con IE9 e IE10, se unió al resto en una constante tendencia a la baja.

Chrome introdujo varios cambios que han adaptado la mayoría de browsers. Eliminaron las versiones, se actualiza silencionamente, fusionó las URLs con la busqueda, los plugins se instalan sin reiniciar, el motor V8 aceleró Javascript al infinito, trajo la sincronización entre dispositivos y aisló por primera vez los tabs por procesos.

Chrome además hizo que Webkit sea el motor de render dominante en el planeta.


Microsoft entendió el error de frenar la web con IE6, 7 y 8. IE9 aceptó a HTML5 y IE10 empezó a competir de manera seria con el resto de los navegadores modernos. Pero es demasiado tarde. Ha ocurrido. La gente normal, no nosotros, no los techies, no los geeks, quieren instalar un navegador mejor.

¡Pero esto es en el primer mundo! ¿Qué pasa con latam?

¿Qué pasa con latam? Pasa algo muy similar. Cristalab no es un indicador del público en general, pero vale la pena resaltar quién entra a nuestra comunidad:


Internet Explorer es una minoría brutal. IE9 es el más usado, seguido por IE8. IE7 sólo representa el 1% de nuestro tráfico y IE6, como en el resto del mundo, no existe. Es hermoso trabajar en Cristalab.

IE6 no existe, IE7 muere rápidamente. Ya casi, compañeros, ya casi somos libres.

¡Postea screenshots de tu propio Analytics y celebremos!

Érase una vez en la web, un campo de batalla

Con la nueva era de HTML5, la web móvil y todas las nuevas tecnologías, mucha gente ha olvidado o simplemente nunca vivió la "Guerra de Navegadores", una época oscura en internet donde todos peleaban contra todos, todos se odiaban entre si, ningun navegador implementaba algo que otro ya lo tenía, y sentía la necesidad de tener su propia versión de dicha característica.

Era como "Game of Thrones", pero en internet.

Ésta página está optimizada para Internet Explorer 5.5 con resoluciones de 800x600

Es esa fecha en la que "Esta página web está diseñada para correr en tu viejo Internet Explorer 5.5 en resoluciones 1024x768 y tu que usas Netscape con 800x600 no me importas" era practicamente ley, y el resto de gente que usaba Netscape u Opera sufría en el olvido.

Señores, esto está ocurriendo otra vez, les presento la nueva guerra de navegadores del 2012 en la era móvil y el pésimo uso de los prefijos de CSS.

Los prefijos de los navegadores en CSS3

Código :

#logo {
   -webkit-animation: annoying_blink_effect 0.150s infinite;
   -webkit-transform: rotate(-15deg);
   -webkit-transition: all 10s linear;
}

Safari, el navegador por defecto del iPhone y iPad, con su motor de rendereado WebKit introdujo muchas caracteristicas que han sido un boom a nivel gráfico para la web, incluyendo a las transiciones, animaciones, transformaciones, y muy pronto Adobe esta implementará los shaders para CSS, que ahora se volvieron parte del estandar de CSS3 - estas nuevas caracteristicas nos han brindado muchas nuevas posibilidades en la web; nuestras apps son mas rapidas, mas bonitas y hasta a veces su interfaz se puede comparar a la de una aplicacion nativa.

Pero esto trajo un nuevo problema, al ser los pioneros, mucha gente empezó a usar estas propiedades sin importarle el resto de navegadores, cada vez vemos menos websites siendo probadas con otros navegadores que usen la última versión de WebKit, y esta resultando en websites muy pobres que solo fueron "Diseñadas para correr en iPhone 4S", olvidando al 3GS o a los Android, ni hablar de los Window Phone, y Opera Mobile... alguien se acuerda de Opera?

Opera en el vacío: "ya nadie me quiere ;__;"

Opera, Microsoft y Mozilla se hartaron, se cansaron que aunque sus navegadores soporten muchas de estas opciones de CSS3, los "diseñadores web" solo estan diseñando, maquetando y programando para WebKit.

Es entonces cuando Opera mandó a los estándares al diablo e implementó los prefijos -webkit- a su navegador en versión "experimental", echando la culpa de todo esto a nosotros, los que trabajan en la web. ¿Y saben qué? Creo que es cierto, muchos de nosotros usan -o, -ms, -moz además de -webkit, y por último muy pocos usan la propiedad SIN los prefijos en su código.

¿Oh, no, y ahora qué podemos hacer?

No mucho, solo rezar que Opera nunca pase esto a su versión estable, esperar a que algún día todos los navegadores decidan dejar de usar prefijos (muy improbable), y aprender a escribir buen CSS.

El estándar indica que uno debe escribirlo su código asi.

Código :

#logo {
   animation: annoying_blink_effect 0.150s infinite;
   transform: rotate(-15deg);
   transition: all 10s linear;
}

Pero esta es la web, los navegadores nunca quieren hacerte la vida fácil, entoncestienes que incluir todos los prefijos de los como se debe, además de la propiedad por defecto.

Código :

#logo {
   -o-animation: annoying_blink_effect 0.150s infinite;
   -ms-animation: annoying_blink_effect 0.150s infinite;
   -moz-animation: annoying_blink_effect 0.150s infinite;
   -webkit-animation: annoying_blink_effect 0.150s infinite;
   animation: annoying_blink_effect 0.150s infinite;

   -o-transform: rotate(-15deg);
   -ms-transform: rotate(-15deg);
   -moz-transform: rotate(-15deg);
   -webkit-transform: rotate(-15deg);
   transform: rotate(-15deg);
   
   -o-transition: all 10s linear;
   -ms-transition: all 10s linear;
   -moz-transition: all 10s linear;
   -webkit-transition: all 10s linear;
   transition: all 10s linear;
}

Pero los prefijos son horribles, arruinan mi código y los odio

Entonces, haz como los pros, aprende a usar pre-procesadores como Stylus, Less o Sass.

Y si por nada del mundo puedes usar uno de ellos, arruina la velocidad de carga de tu web usando prefix free.

Siempre usen los prefijos, no dejen que las empresas detras de los navegadores nos usen de excusa para hacernos la vida imposible.

Adobe hoy anunció Adobe Creative Suite 6 y Adobe Creative Cloud. Adobe CS6 trae mejoras a toda la gama de productos (hasta Fireworks! <3) y Creative Cloud es varias cosas: Una nueva estrategia de precios, un sistema tipo "dropbox" para compartir contenido y una serie de apps que corren en tablets y guardan en la "nube".

Los mensajes principales son: Crear apps nativas para móviles y tablets sin programar. Exportar HTML5 fácil. Hacer todas las apps gráficas más veloces. Cambiar el modelo de pago por software a un modelo de suscripción como servicio.


Puedes ver todos los detalles en tiempo real del cubrimiento si sigues la cuenta de Twitter @cristalab.

Adobe Photoshop CS6

Dos cosas resaltan del nuevo Photoshop: Un aumento gigantesco en rendimiento y velocidad (al fin!) que le permitirá correr incluso en maquinas antiguas y una mejora sobre todos sus algoritmos de recreación de bitmaps.

En Photoshop CS5 vimos los filtros "content aware" y su capacidad de rellenar una fotografía con patrones similares ultrarealistas al querer hacer retoques o borrar detalles. Ahora "content aware" es extendido a cosas como fotos panorámicas o con filtros "ojo de pescado" y otros casos donde las fotografías pierden detalle angular.

Ah y ahora la interfaz se parece a Premiere, gris oscuro. No está mal. Photoshop sigue siendo la joya de la corona, titulo que en un pasado compartió con Flash.

Adobe Photoshop Touch

Un Photoshop para iPad y tablets Android, optimizado para usarlo con dedos o "stylus gordos". Tiene todas las capacidades básicas: Capas, efectos, selección inteligente, filtros, brochas y hasta los algoritmos "edge aware" y "content aware" para no necesitar la precisión de pixel de un desktop. Genera archivos .psd que puede guardar en la "nube" de Creative Cloud o permite compartir los resultados a la cámara del dispositivo, Facebook o por email.

Y cuesta 10 dólares.

Adobe Premiere Pro CS6

Puedo resumirlo en una frase: Premiere CS6 es un editor de video con el poder de Photoshop. La mayoría de los filtros "content aware" ahora son aplicables a videos en movimiento y gracias a "Mercury", el nuevo motor gráfico de Adobe, los cambios se ven casi al instante. Premiere también incluye la detección de profundidad 3D de Photoshop y un "live preview" de efectos y clips que es muy similar al de iMovie o Final Cut Pro.

Adobe Flash CS6

Flash CS6 se siente más como un CS5.5.1, pero es entendible dado el serio recorte de presupuesto que sufrió el equipo de Flash Platform el 2011. Flash CS6 ahora puede exportar animaciones básicas a HTML5 de manera transparente, así como compilar de manera nativa a iPhone, iPad y Android, incluyendo el uso de Stage3D.

La exportación de Flash a HTML5 estará optimizada para CreateJS, un framework de creación de "experiencias interactivas" en HTML5, competencia de ImpactJS o, en cierto modo, jQuery. Especializado en animaciones, audio y video. Creado por Grant Skinner.

Flash quiere ser LA herramienta para crear juegos y experiencias multimedia (como libros interactivos para niños) en móviles y tablets. Sea en el navegador o como app nativa. ¿Lo logrará? Por primera vez hay alternativas, pero Flash seguirá peleando fuerte.

Un -1 para Adobe por hacer el demo de Flash a HTML5 creando un intro, eso sí.

Adobe Dreamweaver CS6

Conozco pocas personas que sigan usando Dreamweaver, pero para los que les gusta, DWCS6 trae un asistente para crear Responsive Design, llamado "Fluid grid layout". También incluye soporte nativo a jQuery Mobile, transiciones CSS3 y la exportación directa de Phonegap.

Dreamweaver aspira a convertirse en el IDE de Phonegap para creación de apps móviles al igual que Flash Builder 4.6 es el IDE de Flash para juegos móviles.

En las cosas pro: Live View de Dreamweaver ahora usa un Webkit actualizado. Ya era hora.

Adobe InDesign CS6

Todo el mundo está migrando del papel a la pantalla y este es un equipo de Adobe que sí supo reaccionar al cambio. InDesign CS6 ahora puede crear revistas y libros interactivos para tablets sin necesidad de escribir una sola linea de código.

Capacidades como Layout Liquido, inserción de contenido externo (videos, Flash, HTML, etc) y forms de PDF se combinan con la habilidad mágica de exportar tu diseño, en un click, como una app nativa para iPhone, iPad o Android gracias a Adobe Digital Publishing.

Aplausos a un equipo dentro de Adobe que ha sabido responder al futuro con buen PR, buenas herramientas y buen contacto con la comunidad.

Adobe Fireworks CS6

Fireworks es el equivalente al hermano gemelo de Bart Simpson. Vive en el ático encerrado, le dan cabezas de pescado y nadie quiere hablar de él, más que para mantenerlo con vida. Nada se dijo de esta herramienta, mi favorita de todas. Fireworks no compite con Photoshop, lo complementa siendo el mejor entorno para combinar bitmaps, vectores y areas sensibles, que luego pueden ser exportadas como prototipos para webs o apps.

Fireworks CS6 ahora puede: Exportar CSS "limpio" analizando el diseño, crear themes para jQuery Mobile, correr más rápido con Mercury. Y ya. Eso es todo. Gracias por las cabezas de pescado.

En sintesis: Not bad

Desde afuera, parecía un lanzamiento aburrido, pero Adobe tuvo anuncios muy interesantes. El más importante de todos, en mi opinión, es la migración a un modelo "Software as a Service" con la suscripción de Creative Cloud.


Extrañé mucho menciones a Fireworks o Illustrator, pero entiendo que querían limitarse a mostrar las apps móviles y los pesos pesados que generan dinero real dentro de Adobe.

La pregunta es para ustedes ¿Vale la pena CS6? ¿Lo comprarán y usarán? ¿Migraron a otra plataforma? ¿O seguirán usando alguna versión vieja de Adobe Creative Suite?

Todas las imágenes de este artículo fueron creadas y optimizadas con Fireworks CS5 </3

Este fin de semana será el Curso de desarrollo de apps para iPhone y Android en Bogotá y el 11 y 12 de mayo, este mismo curso estará en Ciudad de México.

Un curso donde aprenderás las tecnologías con las que se crean aplicaciones móviles compatibles con iPhone, Android y iPad (Y hasta Blackberry si te interesa lo retro). Apps como Wikipedia, Machinarium y hasta Angry Birds para Facebook han sido creadas con los lenguajes que verás en el curso.

¿Qué necesito para ir a estos cursos?

Saber programar y querer crear apps para poder vender (o regalar) en la App Store de Apple o en el Google Play Store de Android. No necesitas más que los conocimientos básicos de programación. Obviamente, si tienes teléfonos o tablets, lleva todo el hardware que quieras para probar.

El curso de Bogotá es este fin de semana, 20 y 21 de abril. Con un valor de $440.000 pesos.
El curso de México DF es el 11 y 12 de mayo. Con un valor de $2.900 pesos.


Ambos cursos pueden pagarse con tarjeta de crédito, Paypal o deposito bancario. Y hay descuentos si vas en grupo, llamando al teléfono de cada curso.

Si tienes más de 100 clabLevel en Cristalab, puedes ir gratis llevando a alguien más. Sólo mandas un mail a [email protected] y tendrás tu entrada.

Jared Wein, uno de los ingenieros de la Mozilla Foundation publicó el anuncio que Firefox 14, la próxima versión de Firefox, no permitirá que Flash cargue en cada página que se abra hasta que el usuario de permiso explicito.

La implementación está aprobada y el desarrollo ya va avanzado, la pregunta que queda es cómo será la interfaz. Las dos opciones son mostrar un cuadrado gris con el texto de clickear para activar (como abajo en la imagen) o una barra amarilla en el header del sitio web, avisando del contenido Flash y dando la posibilidad de activar.

Esta implementación será por URL y por elemento Flash. A menos que se cambie explicitamente en el about:config, todos los SWF requerirán permiso de click para correr.

¿Qué significa esto para los desarrolladores en Flash y Actionscript 3?

Hay 3 tipos de personas que se verán afectados por esta medida: Devs normales de Flash, creadores de banners y sitios que usan Flash de manera invisible.

Para el uso normal de Flash, no significa mucho

A la gran mayoría de las personas que crean en Flash, lo único en lo que los afectará es un click adicional. Si tu sitio es 100% Flash, se verá gris antes que el usuario de el primer click. En algunos casos, esto puede ser imperdonable, en otros, no tan grave.

Aunque a nivel de usabilidad, cualquier click adicional es malo.

Para los creadores de banners: Hora de no usar Flash

En un banner, un click adicional es inviable. Los banners son ultra optimizados para efectividad y rendimiento. Si un banner requiere un click adicional, muertos. PEro lo peor, si un banner NO SE VE sin darle click, ahí ya nos jodimos todos. Con esto, hacer banners en Flash no es rentable ya.

Para quienes usan Flash de manera invisible como "canal"

Grooveshark usa Flash internamente para reproducir la música (Grooveshark no usa HTML5, aunque tienen una versión HTML5). Pandora igual. El audio en HTML5 aun es muy malo (el video no, es genial). Otro ejemplo destacado es Socket.io, que usa Flash en navegadores que no soportan sockets para hacer realtime. Estos casos donde Flash es usado como un "canal invisible" son seriamente afectados. Porque al ser de 1px de tamaño, son Flash invisibles a los que no se les puede hacer click.

¿Soluciones? No tengo ni idea. Hacer visible el SWF y agregar al diseño un "da click aquí para que funcione" es lo que se me ocurre.

¿Para donde va Flash en los desktops?

Repasemos. Flash ya será imposible correr en Windows 8 cuando esté activa la interfaz Metro. Igualmente Safari (aunque sólo se usa en móviles). Adobe abandonó el plugin para móviles y la nueva estrategia de Flash está centrada en el desarrollo de juegos.

Para allá va Flash. Flash será la plataforma cross-device de juegos #1. Ya no una de experiencias interactivas al estilo de GrupoW, 2Advanced o BigSpaceShip, sino juegos móviles en teléfonos y tablets como Angry Birds, Machinarium o Draw Something. Mientras, todavía sirve.

MongoDB es un sistema de bases de datos NoSQL orientado a documentos, a diferencia de MySQL, este no es una base de datos relacional. Es open source, lleva entre nosotros desde el 2009. Está escrito en C++ y tiene intención de aumentar la escalabilidad de un sistema. Es compatible con Linux, OS X, Windows y Solaris.

Además de MongoDB existen otros sistemas NoSQL como por ejemplo Cassandra, CouchDB, Redis, Riak, Membase, Neo4j y HBase.



Considera que mongoDB fue diseñado para ser un motor de búsqueda sobre aplicaciones en la nube, debes de ser bien específico al momento de elegir un sistema NoSQL. Esto porque tienen diferentes funciones o están optimizados para diferentes tareas: Como Cassandra que fue diseñado para búsquedas en Facebook.



Si buscas un framework en PHP para poder utilizar MongoDB inmediatamente puedes probar alguno de los siguientes: CakePHP, Codeigniter, Doctrine, Drupal, Kohana, Lithium, Memcached, Symfony 2, Yii y Zend Framework.

Si buscas utilizarlo con Python prueba con PyMongo.

Conceptos básicos

Una base de datos en MongoDB tiene diferentes conceptos a una base de datos regular como MySQL. Cada registro o unidad básica de datos se le denomina documento. Y cada conjunto de documentos, que formarían una tabla, se le llama colección.

Un documento se podría comprar con el concepto de fila y una colección a una tabla.

Organización y sistema

La ventaja que tiene MongoDB ante las bases de datos racionales es la velocidad de consulta. Esto se logra gracias a que los documentos son almacenados en formato BSON, que es una versión modificada del ya conocido JSON.

BSON pesa un poco más que un JSON regular, pero gracias a que este guarda longitudes de campos, índices de arrays, entre otras cosas, es mucho más rápido (y menos costoso), acceder a la información que se consulta.

Al final del día no vamos a ver el formato BSON, así que no te preocupes, siempre lo leerás como un JSON regular.

Documentos

Los documentos son un conjunto de claves con valores asociados. Sin embargo, cabe destacar que en cada lenguaje es diferente el "output".

Código :

{ "pepito" : "uno" }

Igual cabe destacar que una clave puede contener varios valores asociados como por ejemplo:

Código :

{ "pepito" : "uno", "dos" : 3 }

Notas importantes
- Las claves de un documento son strings.
- No se deben utilizar caracteres como punto y el signo de dólar.
- No deben de comenzar con guión bajo.
- Las claves son sensibles a mayúsculas y minúsculas.
- No debe contener claves duplicadas.
- Cada documento tiene una _id única generada a partir de diversos métodos, así siempre será diferente.

Colecciones

Una colección nos ayuda a organizarnos de manera mucho más fácil y rápida.

Código :

> db.pepito.insert()
> db.pepito.find()
> db.pepito.drop()

Notas importantes
- Mantener diferentes tipos de documentos en una misma colección es de masoquistas.
- Un string vacío no es un nombre válido, así como no se puede utilizar un string con signo de dolar.
- Es más rápido obtener una lista de documentos que mantengan la misma estructura.
- Siempre planea la estructura de tus colecciones y documentos antes de comenzar.

Manejo de datos desde la shell

Ya que este artículo es únicamente una introducción, no entraré en detalles de cómo instalarlo o utilizarlo con algún lenguaje. Únicamente desde la shell que viene por defecto o desde aquí (haciendo clic en "Try It Out")

Para hacer una inserción y guardarla escribimos lo siguiente para obtener algo parecido a pepito = tontito

Código :

db.pepito.save( { "pepito" : "tontito" } )

Y para imprimir el contenido

Código :

db.pepito.find()

El siguiente script inserta en el documento varios elementos en forma de tags, después usa una función para contar cada elemento con un foreach, separa los elementos y devuelve la cantidad de elementos en otro documento.

Código :

$ ./mongo
> db.things.insert( { _id : 1, tags : ['perro', 'gato'] } );
> db.things.insert( { _id : 2, tags : ['gato'] } );
> db.things.insert( { _id : 3, tags : ['raton', 'gato', 'perro'] } );
> db.things.insert( { _id : 4, tags : []  } );

> // función de mapeo
> m = function(){
...    this.tags.forEach(
...        function(z){
...            emit( z , { count : 1 } );
...        }
...    );
...};

> // función reductora
> r = function( key , values ){
...    var total = 0;
...    for ( var i=0; i<values.length; i++ )
...        total += values[i].count;
...    return { count : total };
...};

> res = db.things.mapReduce(m, r, { out : "myoutput" } );
> res
{
   "result" : "myoutput",
   "timeMillis" : 12,
   "counts" : {
      "input" : 4,
      "emit" : 6,
      "output" : 3
   },
   "ok" : 1,
}
> db.myoutput.find()
{"_id" : "gato" , "value" : {"count" : 3}}
{"_id" : "perro" , "value" : {"count" : 2}}
{"_id" : "raton" , "value" : {"count" : 1}}

> db.myoutput.drop()

Existen muchos más comandos, todos ellos están en la documentación, con el comando help, documentación o desde la shell de mongodb.org escribiendo tutorial para un rápido pero informativo tutorial.



¿Tienes dudas? Dejame un comentario aquí o sígueme en twitter @kinduff.

En el próximo tutorial les enseñaré como generar bases de datos, leerlas y modificarlas.

Enlaces de interés

- Página principal de mongoDB [link]
- Documentación mongoDB [link]
- Sourcecode + drivers para diferentes lenguajes y sistemas [link]
- NoSQL: If Only It Was That Easy [link]
- Cassandra vs MongoDB vs CouchDB vs Redis vs Riak vs HBase vs Membase vs Neo4j [link]
- [NSFW] Relational Database Vs NoSQL Fanbois [link]

Wow. Mark Zuckerberg anunció que Facebook compró Instagram por mil millones de dolares (un billón gringo). Instagram nació como una aplicación para aplicar efectos especiales a las fotos tomadas con un iPhone, evolucionó a ser una red social privada de fotografía y la semana pasada anunció su llegada a los teléfonos Android. Es la app de fotos más exitosa de la historia y ahora parte de Facebook.

Y si esta compra no demuestra la burbuja tecnologica, no sé qué más pensar.


Hay 3 cosas que me quedan claras con esta compra:

La creación de contenido en dispositivos móviles es el mercado más caliente del momento

El gran problema de los smartphones y las tablets es que son vistas como dispositivos de consumo, más que plataformas para crear contenido. Apple lo sabe y por eso enfocó al iPad 3 (Pepito) como LA tablet para crear música, editar fotografías, componer videos profesionales y en general: Crear.

En el último mes hubo dos compras gigantes en el mundo móvil: OMGPOP (Draw me Something) por Zynga y ahora Instagram por Facebook. Un juego y una camarita. Dos apps increiblemente exitosas en hacer que los usuarios de móviles creen.

Eso sumado al lanzamiento de la espectacular "Paper" para iPad.

¿Quieres hacer platita? Programa apps móviles que le permitan a los usuarios crear.

¡El dinero ya no vale nada, carajo!

No, en serio, nada. Ayer leía un artículo de un emprendedor elegido por YCombinator donde, en su primera reunión con Venture Capitalists, los inversionistas le tiraban dinero a la cara, le pedían poder unirse a su idea, lo perseguían con pasión. Hay tanto dinero gringo, tantos fondos, tantas valuaciones locas, que la percepción de dinero en el mundo de las startups está en su momento más raro.

Esto es lo que se sentía a finales del 2004. Es lo que se sentía por el 2001. Es la punta de la ola en la burbuja del dinero en internet. Si lograste hacer plata en esta epoca, es hora de comprarte una casa en la playa, contratar a un mayordomo que se cambie el nombre a Alfred y darte por bien servido. Viene la explosión de la burbuja.

Y tengan en mente, esto lo hace Facebook justo antes de salir a la bolsa a levantar aun más plata. Es más rentable aprender a programar que traficar con droga en estas épocas.

Invertir tu tiempo y talento en una app sin modelo de negocio sigue sin tener sentido

Esto es lo que me preocupa de Twitter todos los días de mi vida. Afortunadamente, mi cuenta de Twitter ya amortizó el costo que tiene mantenerla.

Mucha gente publica montones de fotos diarias en Instagram, gente que no sabe si esas fotos seguirán ahí mañana o si a Facebook le da por matar todo, desactivar la conexión con Twitter o hacer la conexión con Facebook "obligatoria". Gran parte del atractivo de Instagram era crear una segunda red de amigos cercanos con quien compartir fotos privadas de los hijos o en el espejo del baño. Lo que siempre quiso y nunca pudo crear Path.

Ahora, no sé sabe qué pasará. Facebook dice que mantendrá todo igual, que Instagram será independiente y bla bla bla. Las empresas cambian de estrategia y de opinión. Palm murió, el Playbook fue un fracaso, Google Wave desapareció, Tweetdeck se estancó, Jaiku fue cerrado, etc, etc, etc. Hoy Instagram sigue viva ¿Mañana?

Esto pasa con las empresas llenas de hype y faltas de ingresos. Eso es una gran adquisición para Facebook ¿Pero le conviene a los usuarios que han invertido meses en crear algo único dentro de Instagram?


Lo que importa es que, hoy más que nunca, crear apps móviles que creen contenido es más valioso que tener una empresa que haga plata. ¡A aprender a programar y que viva la burbuja!

Al final del 2011, se vendieron casi 60 millones de iPads. Las tablet con Android: 6 millones.

Para el final del 2012, habrán cientos de millones de tablets. Una demografía más grande que países enteros. Un mercado gigantesco imposible de ignorar y una experiencia nueva en apps y en web.

Excepto que ninguna otra tablet importa excepto el iPad. Y sospecho que así se mantendrá por lo menos por dos años más.

El objetivo de este artículo no es evaluar el iPad y las tablets Android como productos de consumo sino entender por qué el iPad define la experiencia de tablets. Como creadores de Internet, debemos probar nuestros sitios en todas las pantallas. Pero también reconocer, como con IE6 en el 2004, a la plataforma dominante.

La calidad del iPad y sus apps es simplemente superior

Android no tuvo una guía de diseño seria hasta Ice Cream Sandwich. Apple obviamente ha tenido su HIG desde el día 1 de la App Store. Por eso vemos engendros famosos en Android como el primer reproductor de mp3 comparado con el iPod app de Apple.

ICS (Android 4) puede ser la respuesta para Google. Pero a la fecha, las tablets Android tienen 13.200 apps (4% de las apps totales de Google Play están hechas para Honeycomb o Ice Cream Sandwich), mientras el iPad tiene 140mil.

El navegador de Android 4 es superior en usabilidad a Safari Mobile, pero apps como Paper, GarageBand, iMovie, Keynote o iPhoto no tienen comparación con nada en el mundo Android. Mi principal queja con el iPad 1 es que se convertía en una tableta de consumo pasivo, en vez de creación de contenido. El iPad 2 y el iPad Pepito (iPad 3) solucionaron eso por completo con apps como estas.



Android no tiene apps de creación de contenido equivalente a Apple en ninguna de sus tablets.

De hecho, al día de hoy, Google Play no tiene una sección de apps para tablets, lo máximo es "Staff picks for tablets", pero ¿Y las top paid, las top free?. El iPad la ha tenido desde el día uno.

Safari Mobile vs. ¿Chrome Mobile?

Mencioné arriba que la usabilidad del navegador de Google es superior a Safari Mobile y es verdad. Ice Cream Sandwich maneja mejor la memoria, mantiene vivos los tabs y hasta tiene Flash (excepto que Adobe ya no hará más Flash Player móvil) ¿Pero y en rendimiento?

Javascript tiene mejor rendimiento en iPad 2 y iPad 3 que en el más veloz Android tablet (Asus Transformer Prime). El iPad 3 con su Core A5X es 5 veces más veloz en gráficos 3D que el más veloz core de Android (Tegra 3). Y todo esto mientras el iPad Pepito (new iPad 3) mueve monstruosos 2048x1536 pixeles, contra los 1280x800 del Transformer Prime con ICS.

Esto sumado a 9~10 horas de batería vs. ¿8~7 del Galaxy Tab y del Transformer Prime?


En el mundo HTML5, Safari Mobile supera en multiples campos al navegador por defecto de Android, pero es superado por Chrome Mobile.

Pero entonces... ¿Por qué carajo Chrome Mobile no es el navegador por defecto de Android?. Google tiene el, quizás, mejor browser de la época y decidió crear "otro" para Android, dejando a Chrome móvil en "beta".

En serio ¿Qué están pensando en Google?

La oportunidad de Android está en el precio

Apple está por lo menos dos años adelante de Android en calidad de apps, usabilidad, cantidad de apps que crean contenido y calidad de hardware

¿Entonces qué hago? ¿Me compro un iPad, mato mi Android? ¿Qué hago?

Yo tengo un Samsung Galaxy Nexus corriendo Ice Cream Sandwich. Lo amo. Es la mejor experiencia móvil que he vivido y no lo cambiaría por nada. ¿Mi Galaxy Tab 10.1? Lo cambiaría sin pensar por un iPad Pepito. Por alguna razón, Google no ha podido competir en tablets al nivel que ha competido en teléfonos.

El Amazon Kindle ha vendido bien, a pesar de ser una experiencia completamente desconectada de Android. Hay rumores que Google planea vender tablets por su propia cuenta con ICS por precios menores a 200 dólares.

Con precio y volumen, Google puede ser capaz de retomar dominio sobre las tablets como lo tiene sobre los teléfonos.

Sin embargo, en el futuro, las condiciones para crear webs para tablets a futuro seguirán siendo la "Retina" 1024x768, el render de Safari Mobile y los specs del iPad. No hay que ignorar a Android, pero es una muy mala idea no tener un iPad si haces desarrollo web.

Es en el iPad donde debemos inspirarnos para crear nuevas experiencias. Es al iPad al que hay que apuntar primero al construir sitios para tablets. Y es un iPad la herramienta que necesitamos, por encima de cualquier otra tablet, para testear nuestros desarrollos en la nueva forma de usar la web.