Mobile First, porque el (menor) tamaño sí importa

Ya en otras oportunidades (menos de las que quisiera) hemos conversado en este blog sobre Responsive Web Design y Mobile First. Lo que ha hecho creer a la gente (incorrectamente) yo realmente sé algo al respecto, sólo porque nunca han visto lo increíblemente bueno que soy como jinete acrobático de ponis…

En fin, gracias a eso, tuve el honor de ser invitado de nuevo a hacer una presentación en la reunión número 29 del Refresh Valencia, un proyecto del que ya he hablado antes y que realmente me gusta mucho y trato de apoyar tanto como pueda, por lo que –a pesar de que cada vez que me dispongo a hacer el viaje de Caracas a Valencia y llegar a tiempo, algo pasa (es lo que yo llamo “mi maldición del Refresh”)–   no podía decir que no y, no después de mucho trabajo, y llegar casi demasiado tarde, pude encontrarme con los amigos y hablar un poco de lo que he aprendido al respecto.

Como dije, ya hemos conversado antes de este asunto en el blog, pero lo interesante de estos temas es que siempre hay campo para aprender cosas nuevas y mejorar, y espero que la presentación haya cumplido el objetivo. Si no fue así, al menos pueden creer que me divertí mucho haciéndola.

Hace ya un tiempo de esto, pero por alguna razón no lo había publicado en el blog, y creo que vale la pena, por lo que voy a pagar mi deuda dejándoles acá el enlace por si están interesados:

Como siempre, el problema de los slides es que les falta contexto, así que si hay algo que no entienden, que quisieran discutir o simplemente no están de acuerdo, siéntanse libres de decirlo en los comentarios.

Usar distintas credenciales ssh con Git

Como freelancer, no es extraño que en algún momento te veas en la necesidad de trabajar en el  repositorio remoto de alguna empresa mientras mantienes también uno para tus propios proyectos. En estos casos es posible que ambos esten en servicios diferentes (Github y Bitbucket, por ejemplo) o que simplemente te hayan asignado un correo distinto al tuyo para trabajar con estos repositorios. Incluso es posible -como es mi caso-, que uses el mismo servicio que la compañía con la que trabajas, pero al usar distintos usuarios, no es posible utilizar la misma credencial ssh para ambos perfiles y debas crear una para cada usuario.

Si éste es tu problema, te habrás dado cuenta que no te es posible, así como así, decirle a Git cuál credencial debería usar para cuál cuenta. En mi caso, se sumó el inconveniente de que necesitaba hacer esto en Windows y la mayor parte de la información en la red (que no es abundante precisamente) está centrada en sistemas *NIX, lo que significó un trabajo extra pero que realmente no lo hace más complicado una vez  que lo entiendes.

Importante: Este no es un artículo sobre cómo usar Git. Si te has encontrado con este problema, seguramente ya entiendes algo de Git (al menos lo básico), si no es así, te recomiendo que veas la documentación en http://git-scm.com/

Crear las credenciales

Para crear las credenciales es necesario que tengamos instalado SSH. Si trabajas con Linux o Mac no debes preocuparte porque viene preinstalado, igual que Git (sí es buena asegurarte que trabajas con la versión más reciente), si trabajas con Windows puedes matar dos pájaros de un tiro instalando Git. El sitio oficial de  Git es http://git-scm.com/, donde también puedes mirar la instalación para Linux, OS X y Solaris en la sección de Downloads. También puedes hacer uso de su documentación si estás aprendiendo  cómo usarlo.

Dos consejos a los usuarios de Windows:

  1. Selecciona correr Git usando msysgit. De esa manera no harás cambios mayores al sistema y podrás echar mano de otros comandos propios de Unix.
  2. Selecciona convertir el fin de línea (Windows finaliza los archivos de manera distinta a *NIX, lo que puede ser un problema si trabajas en grupo o en un proyecto Open Source, donde encontrarás gente trabajando en Linux o Mac). No te preocupes, no interferirá con tu trabajo.

Una vez que tenemos lo que necesitamos, abrimos la terminal (o símbolo de sistema, en Windows) y ejecutamos el siguiente comando:

ssh-keygen -t rsa

Lo primero que nos pedirá es que le digamos dónde queremos que guarde el archivo, mostrándonos la dirección y el nombre por defecto. Por defecto, las credenciales se guardan en /home/nombre_de_usuario/.ssh (C:\Users\nombre_de_usuario\.ssh en Windows), guardémoslas  allí. Si vas  a ponerle un nombre distinto al nombre por defecto, debes colocar también la dirección donde se guardará, de lo contrario, se guardará en la carpeta en la que estás en ese momento.

Una vez colocado el nombre, te pedirá que coloques una contraseña para proteger el archivo, lo que es muy buena idea si vas a usar estos archivos en una máquina compartida, en la laptop u otro sitio suceptible de que alguien más pueda usarlos sin tu permiso.

Si todo sale bien,  en la carpeta correspondiente  tendrás el archivo que creaste, sin extensión, más otro del mismo nombre con extensión .pub. Este segundo archivo es la clave pública, que en algunos casos podrás subir al servidor remoto al que quieres comunicarte para hacer la verificación.

Pero ¿qué pasa si el servidor remoto no me deja subir el archivo? Simplemente abres el archivo pub en el editor de texto, copias la clave y la pegas donde corresponda.

Vincular la credencial con la cuenta correspondiente

Bien, ya tenemos nuestras credenciales, ahora lo que necesitamos es vincular cada una de ellas con la cuenta correspondiente, de modo que  Git  sepa cuál debe usar en cada caso.

Lo primero que haremos es crear un archivo config en la carpeta .ssh, esto puedes hacerlo desde el terminal, usando el comando:

vim ~/.ssh/config

que abrirá el archivo config o lo creará en caso de que no lo encuentre. Claro, puedes usar el editor de texto que prefieras, es sólo un archivo de texto plano.

Ahora, para cada una de las cuentas, colocaremos lo siguiente:

Host nombre_de_nuestro_host
  Hostname host_del_servicio #bitbucket.org, github.com o el que corresponda
  User git
  IdentifyFile dirección_de_la_credencial #p.e. C:/Users/CharlieSheen/.ssh/just_wining_duh_rsa
  IdentitiesOnly yes

Una rápida explicación:

Host: El nombre que desees agregarle a cada cuenta, queda de tu parte. Mi recomendación es que sea corto, para que no tengas que estar escribiendo de más cuando te toque escribir la dirección, yo uso cosas como freelance, github o el nombre de la compañía a la que corresponde la cuenta. Por supuesto, sin espacios ni caracteres especiales. Este nombre va a reemplazar el host y el nombre de usuario en la dirección git. Luego veremos cómo.

Hostname: El host del repositorio: Bitbucket (bitbucket.org), Github (github.com), etc. Recuerda, es el nombre del host, no la url. Nada de http-https, etc.

User: El nombre del usuario usado en el repositorio. Normalmente es git (como en git@github.com:usuario/repositorio.git), pero podría cambiar dependiendo de cómo esté configurado, lo sabrás viendo la dirección git.

IdentifyFile: La dirección de la credencial correspondiente a esta cuenta. Para evitar posibles problemas, es recomendable usar la dirección absoluta). Recuerda, debe ser el archivo de credencial privado, no el público (*.pub)

IdentitiesOnly: Le dice a ssh que sólo debe ofrecer la(s) credencial(es) que está(n) en IdentityFile, evitando exponer cualquier otra llave cargada en el agente ssh, por ejemplo.

Una vez que hayas seguido estos pasos para todas las cuentas que quieres usar, guarda el archivo. En vim usas

:wq

Usar las cuentas vinculadas

Bien, lo difícil ya pasó, lo que debemos hacer ahora es utilizar los vínculos que hemos creado para acceder a nuestros repositorios. Tan simple como esto:

Digamos que nuestro repo es git@github.com:thefricky/wp-simple-twitter-widget.git

Lo que haremos es, a la hora de clonar o asignar el repositorio remoto, cambiar el nombre de usuario (git) y el nombre del host (github.com) por el nombre de host que hemos puesto, quedando nombre_de_nuestro_host:thefricky/wp-simple-twitter-widget.git.

Es decir, si este host lo usas para tus proyectos Open Source y lo llamaste opensource, la dirección que usarás en git será opensource:thefricky/wp-simple-twitter-widget.git

Y eso es todo, en adelante usarás Git como de costumbre sin tener que preocuparte de ser rechazado por el repositorio por culpa de las credenciales.

Happy Coding!

 

Technorati Tags: ,,

Responsive Web Design – One Web to Rule them All

Responsive Web Design Chart

La web es un mundo en constante movimiento, donde los cambios se dan vertiginosamente y en el que mantener el espíritu de siempre aprendiz es vital para mantenerse al ritmo.

La aparición del primer iPhone, y con él la era de los smartphones con navegadores de verdad fue una nueva vuelta de tuerca en una web donde nuestro querido CSS 2.1 y su atributo “media” (que nos permite aplicar una hoja de estilos específica para impresión, “handsets”, etc.) no pudo responder a los retos que se le planteaban, básicamente porque los fabricantes hacían poco o ningún esfuerzo por implementarlo correctamente.

Los dispositivos comenzaron a salir y el reto se hacía cada vez mayor: ¿Cómo adaptar nuestro sitio para que se vea bien en la mayor cantidad de dispositivos posibles? ¿Hago un sitio fijo y que cada quién lo vea como pueda? ¿Un layout líquido/elástico que se adapte a las distintas pantallas y resoluciones? ¿Mejor un diseño para cada dispositivo (móvil, tablet, monitor) y redirigir al que corresponda? Sí, las cosas se complicaron, y aún se complican.

En mayo de 2010, Ethan Marcotte escribió un artículo en A List Apart (y más tarde un libro con el mismo nombre que no me canso de recomendar) sobre lo que llamó: Responsive Web Design, inspirado por una tendencia de la arquitectura moderna, conocida como responsive architecture y el, en mi opinión, brillante artículo escrito en el 2000 por John Allsopp: A Dao of Web Design. En él presenta su propuesta de crear un sistema que permita adaptar nuestro sitio a los distintos dispositivos en los que será visualizado. Para ello, Ethan hace uso de tres técnicas:

  1. Fluid Grids (Cuadrículas fluídas/líquidas).
  2. Fluid Images (Imágenes fluídas/líquidas).
  3. Media Queries.

La intención detrás del Responsive Design no es simplemente crear un sitio que pueda ser visto correctamente independientemente del dispositivo sino que además pueda ser también accesible, legible y usable en diferentes ambientes, sobre todo en un mundo donde la proliferación de tamaños, resoluciones y modos de uso aumenta cada vez más haciendo imposible predecir desde dónde será leída la información de nuestro sitio y por tanto crear una interfaz para cada caso una tarea insostenible o, cuando menos, sumamente costosa.

Por supuesto, a medida que aumentó la adopción de CSS3, RWD ha ido creciendo en popularidad, saltando incluso del campo de CSS hacia Javascript, para superar las dificultades que se han ido presentando en la implementación de un sitio responsivo.

En los siguientes artículos de esta serie profundizaremos en las técnicas de CSS que conforman el Responsive Web Design, al final hablaremos también de sus ventajas, sus desventajas, la forma óptima de aplicarlo y veremos luego algunos recursos que la comunidad frontend ha desarrollado a su alrededor.

Nota: La imagen que encabeza este post es tomada de Beginners Intro: Considering Responsive Web Design, por Harry Wiseman para Inspiration Feed.

HTML5 sin el bullshit – una visión técnica

html5_no_bullshit

HTML5 es el mantra del momento. Por todas partes ves artículos, ofertas de “hacemos tu sitio en HTML5”, clases de HTML5, aplicaciones, etc. Sin embargo, el mantra sirve para vender casi cualquier cosa en la web y las aplicaciones modernas, haciendo las cosas un poco confusas desde el punto de vista técnico.

La razón de esto es que HTML5 es realmente dos cosas: Por un lado, es la nueva versión (aún en desarrollo) del estándar del Lenguaje de Marcado de Hipertexto (HTML, por sus siglas en inglés), médula espinal de la web y encargado de dotar de estructura a los documentos que la componen. Por otro  es una marca sombrilla, que incluye, no sólo HTML sino también la versión 3 del estándar de Hojas de Estilo en Cascada (CSS3) y el lenguaje de programación del lado del cliente (y ahora también del lado del servidor), JavaScript.

El primer aspecto es el técnico, lo que corresponde a HTML como tal, el segundo es un elemento de marketing que procura impulsar el uso y la forma como los usuarios ven los avances que surgen en la tecnología web. A causa de esto vemos en no pocas ocasiones que muchos desarrolladores, dueños de empresas, maquetadores, publicistas del new media le agregan la coletilla HTML5 a cualquier desarrollo, tema de WordPress, curso, charla, sitio web o webapp que realizan, simplemente porque suena mejor que decir animaciones hechas con CSS3 o librería/plugin en JavaScript. Este elemento de marketing es el que no en pocas ocasiones termina por confundir a mucha gente, metiendo en el tren de HTML5 lo que es y lo que no, dejándonos con algo difícil de comprender bien, es decir, bullshit (web 2.0 anyone?).

Mi intención en este artículo no es ponerme en favor o en contra de la gente que hace marketing, ni decirles qué hacer o no, lo que pretendo acá es explicar claramente lo que es HTML5 y lo que no, desde un punto de vista técnico, y cómo las distintas tecnologías etiquetadas como HTML5 convergen, ya sea por necesidad o simplemente por casualidad.

Pero ¿qué carrizo es HTML5?

Ya lo dijimos antes, propiamente hablando, HTML5 es la nueva versión del estándar HTML, que nos ha acompañado desde el principio de la web como la conocemos y que ha pasado por varias transformaciones (cinco en la versión HTML y tres en XHTML o HTML Extendido). Lo que hace HTML es dar al browser las instrucciones que necesita para darle estructura a un documento, decirle cuál es el encabezado, cuál es cuerpo del documento, cuáles son los títulos principales (en HTML hay 6 niveles de títulos), cuáles los párrafos, etc. La forma correcta de darle significado a esta estructura es lo que conocemos como maquetar un sitio.

Pero no sólo se trata de estructura, HTML5 provee también una serie de atributos (es así como se llaman las propiedades de los elementos en HTML) que permiten agregar mayor significado a las etiquetas. Algunos de ellos vienen heredados de las versiones anteriores de HTML y xHTML (como los atributos rel y rev o el atributo accesskey) y otros son propios de HTML5, como el atributo data-, que permite a los maquetadores enriquecer con cualquier tipo de dato un elemento HTML sin afectar la presentación, es lo que conocemos como metadata. Este tipo de mejoras en las etiquetas HTML permiten un mejor aprovechamiento del contenido por parte de los desarrolladores / maquetadores e incluso buscadores. Un ejemplo de esto es lo que se conoce como microformatos.

Voy a repetirlo: HTML es la médula espinal de la web. Es a través de él que lo que hacemos se presenta, ya sea en modo de un sitio (sea de una o varias páginas) o una webapp e incluso, gracias a geniales proyectos como PhoneGap, una aplicación móvil en toda la extensión de la palabra.

HTML5 es la nueva “gran cosa” en la web

¿Qué es lo que hace a HTML5 tan genial, lo que hace que cada vez más y más gente se abalance sobre él sin pensarlo y lo que ha hecho que la gente que hace internet haya cambiado radicalmente su manera de pensar sobre la creación de documentos? HTML5, como concepto, quiere ir más allá de la simple creación de documentos correctamente estructurados y ha dado paso al siguiente nivel: la web de aplicaciones.

Ya no sólo se trata de si tenemos etiquetas semánticas que nos dicen cuál es el encabezado (<header>) o el pie (<footer>) de nuestro documento, o que podamos dividir las unidades de contenidos en artículos (<article>) o secciones (<section>) sino que esta nueva versión tiene en mente la posibilidad de crear, apoyándose en otros estándares (entre los que destacan CSS, JavaScript, y opcionalmente algún lenguaje de desarrollo del lado del servidor), aplicaciones completamente funcionales que pueden correrse desde el browser, sin necesidad de utilizar tecnologías de terceros y/o plugins.

Esto, que es precisamente lo que hace a HTML5 tan revolucionario en el mundo web, apoyado en otros estándares/tecnologías, (de los que hablaremos más adelante) es también el punto donde el aspecto técnico y el comercial se unen y donde el bullshit tiene su lugar.

En próximos artículos hablaremos de las tecnologías asociadas a HTML5 y cómo ellas a su vez contribuyen al conjunto sin perder su independencia o su flexibilidad para trabajar (en la mayoría de los casos) con otras versiones de HTML.

Antes de terminar quiero volver a dejar esto en claro: Este artículo y los que le seguirán están pensados desde un punto de vista exclusivamente técnico y es desde ese punto de vista que debe ser considerado. Cualquier otro tipo de acercamiento no está contemplado en estos artículos –excepto en los casos en que un servidor los considera, nuevamente desde el aspecto técnico, bullshit–. Si a ud. le parece que lo que se dice acá no es correcto porque la W3C dijo que todo eso es HTML5, llegó al lugar equivocado, yo de marketing sé poco o nada y, en los términos de este blog, me interesa poco o nada también.

Flash, Adobe y la web

Realmente este es un artículo que se ha tomado su tiempo en ser escrito, y así debía ser para poder procesar todo lo que ha estado pasando esta semana en el mundo de Adobe, informarme lo mejor que he podido y sacar lo más posible los sentimientos personales de la ecuación.

No es que sea algo fácil de hacer. Si bien mis días de trabajar en Flash han quedado muy atrás y desde hace ya varios años me he dedicado más a HTML, CSS y Javascript, además de PHP en el backend, tengo muy buenos recuerdos de éste desde que pertenecía a Macromedia. Es por eso que mi primera reacción fue de dolor y tristeza, como quien ve un buen y viejo amigo golpeado y magullado. Pero bueno, no se trata de hablar de mi background, así que vamos al tema.

Antes de otra cosa, una aclaración: Este es mi blog personal y aquí hablo en tono personal, no como manager del Adobe User Group Venezuela ni en ningún caso en nombre de Adobe. Toda la responsabilidad de lo dicho aquí recae sobre mí y estas son sólo mis opiniones. Esto va a ser largo, así que búscate un café antes de empezar.

El primer shock que recibió la comunidad fue el despido de 750 empleados de Adobe alrededor del mundo, aproximadamente un 8% de su personal. Fue una noticia que dejó a todo el mundo impactado, empleados, miembros de los grupos de usuarios y gente relacionada a la tecnología y los negocios en general. Los AUG’s (Adobe User Groups) de Latinoamérica  y España sentimos esto en carne propia al enterarnos que John Koch, quien hasta entonces fungía como International Community Manager para Latinoamérica y Asia, era parte de ese grupo. Hay que decir que su trabajo y pasión puso a los grupos de usuarios hispanoparlantes de nuevo en el mapa y nos dio una voz en Adobe. Por eso y más, muchas gracias John.

Como si fuese poco, ese mismo día nos enteramos, sin más, que Adobe había decidido dejar de mantener el Flash Player para dispositivos móviles, y de eso tenemos que hablar con más calma.

No más versiones de Flash Player para móviles

Más allá de las pasiones que esto pueda generar en la comunidad Flash, esto es algo bueno, o cuando menos habría sido irrelevante de haber sido manejado mejor. El hecho es que muy poco o nada se estaba haciendo con Flash para la web móvil. Desde que es posible crear aplicaciones en Flash/Flex y empaquetarlos como aplicaciones para los distintos dispositivos, ése ha sido el camino que la mayoría de los desarrolladores en Flash han estado tomando y ahora mismo las tiendas de aplicaciones de Apple y Android cuentan con ellos. La cosa es que, al ser empaquetados como aplicaciones, el público general no sabe si están hechos en Flash/Flex o alguna otra plataforma, como es el comentado caso de Machinarium, el juego creado en Flash que estuvo de número uno de descargas en iPad en la Apple Store.

La verdad sea dicha, el Flash Player no pudo realmente conseguirlo en dispositivos móviles, frente a lo que hay dos puntos de vista en la web: Por un lado, están quienes alegan que Flash Player era inestable y con un pobre rendimiento en móviles, por otro lado, están quienes afirman que esto se debe al hecho de que la mayor parte del contenido que veía en la web móvil no estaba preparado para estos dispositivos. Hay que decir acá que, lamentablemente, la facilidad de uso de Flash ha sido al mismo tiempo su bendición y su maldición, permitiendo que exista en la web una buena cantidad de contenido pobremente realizado y mal optimizado y esto, junto al “Steve Jobs Phenomenon” (que no voy a discutir ahora acá), ha predispuesto negativamente a mucha gente hacia la herramienta y a veces con razón.

Ahora un par de datos importantes: El que Adobe decidiera dejar de desarrollar futuras versiones del Flash Player para móviles no significa que el Player para móviles dejará de funcionar, si ud. lo usa podrá seguir haciéndolo en base a las limitaciones que presente ahora mismo, simplemente ocurre lo mismo que ocurre con Adobe AIR en Linux, que dejó de ser desarrollado en la versión 2.6. Claro que lo más probable es que eventualmente ocurra lo mismo: que dejen de ser usados (y el Flash Player para móviles más rápidamente), pero, por ejemplo, yo uso TweetDeck en Ubuntu sin problemas ahora mismo, con Adobe AIR 2.6, y la verdad es que no tengo quejas al respecto.

Otra cosa importante de aclarar es que Flash Player y Flash Player para móviles son dos proyectos diferentes, lo que quiere decir que la decisión de abandonar el segundo no implica que el primero también sea abandonado. Al menos no existe de momento ningún indicio al respecto y la misma Adobe ha afirmado que, mientras FP 11.1 será la última actualización del FPM (Flash Player para Móviles), aún trabajan en su hermano para desktop y están ahora mismo desarrollando la versión 12.

También creo que debo insistir en que Flash, como plataforma no ha muerto ni hay indicios de que muera pronto. Ahora mismo hay un mercado creciente en el mundo de las aplicaciones y el desarrollo de experiencias multimedia en 3D que es perfectamente explotable con Flash, a lo que se une el anuncio de la Gran A de sus intenciones de agregar capacidad de exportar de Flash a HTML5 en las próximas versiones del programa. No es que ignore el hecho de que el modo como fue anunciada la muerte del FPM ha golpeado tremendamente a toda la plataforma (eso y el anuncio respecto a Flex, del que hablaremos más tarde), dando la impresión de que es un elefante moribundo, pero más allá de los rumores (los ciertos y los falsos), es un hecho que aún hay cosas que pueden hacerse y van a seguir haciéndose con Flash, dentro y fuera de la web.

Lamentablemente, creo que la terrible forma como Adobe trató esto en su comunicado puso a toda la plataforma en una situación difícil, cuyas consecuencias aún no podemos predecir. Si Adobe hubiese dicho simplemente “Hey, ahora vamos a potenciar la creación de aplicaciones con AIR y, en vista de que la tendencia en móviles es esa y no la web, no seguiremos desarrollando el Flash Player para móviles” habría evitado muchos intentos de justificación posterior y esta mala situación en la que los desarrolladores de Flash/Flex se sienten ahora. Nadie puso el grito al cielo cuando, al anunciar la adquisición de Nitobi dijeron que PhoneGap pasaría a la Apache Foundation, y esa es la misma situación en la que se encuentra Flex ahora mismo.

¿Qué deberían hacer lo “Flash developers” ahora?

Éste es un punto al que ansiaba llegar. El momento en que Flash se volvió popular para la web hizo que bajo su sombra se conglomeraran personas con los más variados perfiles: diseñadores que querían crear experiencias interactivas para la web sin tener que aprender nada o casi nada de código, flasheros (como son llamados comúnmente) que entendían que Web = Flash, desarrolladores que iban más allá de la web, aprovechando sus características multimedia para presentaciones, juegos, aplicaciones, etc.

En mi humilde opinión, éste es un momento para tomar decisiones claras. Si lo tuyo es la web, ya deberías haber aprendido HTML, CSS y Javascript, porque de eso es de lo que está hecho la web, no ahora, no por HTML5, sino porque siempre ha sido así y la tendencia de más HTML y menos Flash en la web puede ser cualquier cosa menos algo nuevo. Es verdad que la rápida adopción de HTML5 ha acelerado esto, pero ha sido sólo un empujón de una tendencia que ya existía antes de él (y la razón principal por la que, por ejemplo, yo mismo dejé de usar Flash en mi trabajo).

Si por el contrario, lo tuyo es Flash/Flex o la Flash Plattform en general, es el momento de atacar el mercado de las aplicaciones, precisamente con la disminución de la presencia del Flash Player, Adobe comenzó a mirar en otras direcciones (TV, aplicaciones para móviles, etc.) y si el desarrollo en Flash Plattform es lo que te gusta hacer, deberías mirar hacia allá también. Como decía, existe todavía un importante mercado en el que Flash tiene aún lugar. Incluso ahora mismo, e incluso cuando Windows 8 sea un realidad en producción, la web es parte de ese mercado (la de escritorio), menos que antes y que quizá disminuya con el tiempo, pero todavía es cierto aquello de que Flash está ahí para proveer aquello que HTML y sus amigos aún no pueden (por ejemplo, DRM, 3D con aceleración por hardware, etc.).

Para lo que no hay espacio ahora mismo (y nunca debió haber) es para el mal uso o el abuso de Flash, no importa lo que Macromedia, Adobe o los usuarios hayan pensado o dicho al respecto. Lo siento, pero si vas a hacer algo deberías poner todo tu esfuerzo en hacerlo bien. No hay lugar para la mediocridad en esto.

¿Y qué pasó con Flex?

Bueno, luego de la bomba (que repito, no debió ser tal, pero es lo que es) que significó el primer día de Adobe, al día siguiente se anuncia que Adobe entregará el SDK de Flex a un grupo después de liberar la versión 4.6, el 29 de noviembre de este año. El grupo estará conformado por miembros del actual equipo de desarrollo, desarrolladores de la propia comunidad y contribuyentes de algunas de las compañías que están trabajando ahora mismo con Flex.

En cierto modo, no parece tan grave, en el sentido que el SDK de Flex siempre ha sido Open Source y lo seguirá siendo. Lo que convierte las cosas en una situación difícil es que, en el mismo artículo, se dice que Adobe recomienda el uso de HTML5 en el largo término, poniendo una sombra de inestabilidad que no resulta nada fácil para los desarrolladores o las empresas que se dedican a ofrecer soluciones empresariales a través de Flex, ni siquiera cuando el mismo Adobe diga seguir comprometido con el desarrollo de Flex y el FlashBuilder. Sí, las cosas para la comunidad Flex no se ven demasiado prometedoras.

Pueden ver un panorama más claro de estas noticias en el artículo de Lime Rocket: Flash, Flex & AIR Future – via Adobe

HTML5 aún no está a la altura para este desafío

Por mucho que me guste HTML5 y sus tecnologías relacionadas, sobre todo las cosas que CSS3 y Javascript han logrado en los últimos tiempos, hay mucho de este tema que aún es promesa a futuro. Todavía lidiamos en un mundo de Internet Explorer 8, Javascript aún no tiene aceleración por hardware (como lo tiene, por ejemplo Flash Player 11) o manejo de sonido surround, o cancelación de eco al nivel de aquel. WebGL es un gran proyecto, pero aún está lejos de ser una alternativa seria… En fin, si los desarrolladores deciden dejar de usar Flash en la web, como consecuencia de todo esto, lo que veremos en el mundo web será un retroceso hasta donde HTML5, CSS3 y Javascript pueden ofrecernos ahora mismo, con la esperanza de que eventualmente lleguemos a estar de nuevo al nivel en que estamos ahora mismo con Flash. Quiero dejarlo claro una vez más, esto no es cuestión de fanboísmo ni preferencias, es lo que es. Eso de que HTML5 puede hacer todo lo que hace Flash ahora mismo es, en el mejor de los casos, un deseo, y en el peor, una mentira.

Aún cuando Adobe afirme que ahora apunta sus armas hacia HTML5, esté desarrollando herramientas de animación, como Edge y prometa la capacidad de importación a HTML5, Javascript y CSS3 en las próximas versiones de Flash, hay mucho camino que andar aún en esa vía y todavía queda pendiente el modo como los diferentes exploradores lidiarán con ello.

Curiosamente, esto no afectará demasiado la web móvil en particular, no es muy diferente a lo que está pasando ahora mismo en ella, pero sí es un impacto (sentido o no) en la web en general y pasar esto por alto no es más que jugar al conformismo, eso es triste.

¿Y entonces, qué viene? Es difícil de decirlo. bastante difícil, por un lado es posible que los desarrolladores en Flash/Flex decidan abandonar estas herramientas y prefieran dedicarse a Javascript o HTML + CSS, otro escenario posible es que estos mismos desarrolladores decidan subir el listón y comiencen a crearse cada vez mejores aplicaciones que justifiquen el uso del Flash Player en el escritorio, con su contraparte como aplicación en AIR para teléfonos y tablets. Un tercer escenario es expandir los conocimientos hacia ambas plataformas, como ha hecho Grant Skinner uno de los más renombrados desarrolladores en ActionScript, cuya agencia no se limita a Flash o HTML5, sino que abarca otras tecnologías y lenguajes.

Lo que sí está claro es que no es momento de sentarse a ver qué es lo que pasará en la web del futuro, es tiempo de tomar decisiones que creen esa web porque la verdad es que la web es de quienes la hacen, no de quienes esperan a que llegue su momento.

Nota: El gran Luís Sosa me mostró anoche Jangaroo, un proyecto Open Source que, básicamente, permite crear frameworks y aplicaciones en Javascript usando ActionScript 3. Por lo que vi, el proyecto parece prometedor y creo que le vendría bien a los desarrolladores en ActionScript 3 darle un vistazo. Eso sí, tengan cuidado de no quemar el CPU de sus clientes Guiño

Repensando la web móvil

Es verdad que la aparición de los smartphones y luego las tablets nos han hecho cambiar la forma como usuarios y desarrolladores miran la web. Un cambio que, de la mano con las redes sociales nos ha invadido de forma, a la vez, avasallante y emocionante.

HTML5, CSS3, Responsive Web, jQuery mobile, Sencha Touch, Titanium, Phonegapp, etc. dibujan un mundo nuevo y muy interesante para diseñadores y desarrolladores, no sólo por darnos un nuevo mercado sino por las características particulares que éste tiene, obligándonos a adaptarnos a las nuevas tendencias.

Sin embargo hay cosas que no han cambiado demasiado. Aún estamos pensando el mundo al revés –según creo– pasando del escritorio, de la “Web Completa” a los móviles, pensando en términos de Gracefull Degradation en vez de Progressive Enhancement. Esto, lejos de ser inocuo para la web, implica ciertos problemas, retos que aún no hemos superado porque enfrentar estos retos implica un cambio drástico, de 180º, en el modo como vemos y como desarrollamos la web del presente y perfilamos la web del futuro.

Hace ya casi un año, Bryan Rieger, nos mostró las implicaciones que este modo de asumir el mundo móvil trae consigo y la necesidad de repensar el modo como decidimos enfrentarnos a ella en su presentación Rethinking the Mobile Web, a pragmatic look at creating an accesible and inclusive mobile experience. Una verdadera joya que vale cada una de las 140 páginas que contiene.

Un material que sin duda nos pone a pensar en qué es realmente la web móvil y en cómo incluir en ella todo un universo de smartphones que, si bien no son iPhones o Androids, son, no sólo más numerosos sino también dignos de ser parte de este modo de hacer web (y claro, también pertenecen a potenciales clientes).

Acá les dejo la presentación, espero que la disfruten tanto como lo hice yo.

Bryan Rieger es diseñador web, quien junto a su pareja Stephanie conforma Yiibu, una consultora sobre experiencia de usuario localizada en Londres, Inglaterra.

Aprendiendo Python con “Python para Todos”

Portada del libro Python para TodosPor cuestiones del trabajo y por curiosidad personal, me puse a buscar algún buen tutorial de Python, que es uno de esos lenguajes a los que les he estado dando las típicas largas de no tener tiempo en ese momento.

Por fortuna, los primeros días de Año Nuevo no resultaron ser tan ocupados como pensaba y, contando con que era fin de semana, aproveché de darle una mirada a una pequeña joya que me encontré gracias a Google: se trata del libro en PDF Python para Todos, de Raúl González Duque. Básicamente se trata de una compilación de los conceptos que expone en su blog, mundogeek.net y es realmente una excelente herramienta para quien desee iniciarse en este lenguaje.

No importa si eres un programador experimentado o apenas estás iniciándote en las lides de escribir código, Python para Todos te llevará paso a paso, desde los tipos básicos (número, cadena, booleano) hasta la distribución de aplicaciones. La verdadera diferencia entre uno y otro nivel es simplemente que el programador experimentado se saltará algunas páginas que quien se inicia no querrá dejar de leer.

Es un libro realmente de fácil lectura y una buena forma de comenzar con este lenguaje. Además, Raúl promete mantener versiones actualizadas cuando resulte conveniente, y, por si fuese poco, es totalmente gratis. Licenciado bajo Creative Commons 2.5, ahora mismo cuenta con 160 páginas, pero no dejes que eso te desaliente porque realmente se lee rápido, yo llevo ya casi un cuarto del libro en un par de días en los que no le he dedicado más de unas tres horas cada día sin saltarme ninguna página.

Así que si estás buscando algún tutorial para aprender Python, y además en el idioma de Cervantes, te recomiendo que le des una mirada a Python para Todos, posiblemente termines disfrutándolo.