Crear aplicaciones offline con HTML5

ByLuis

Cuando cada día la gente está más online, no está de mal del todo permitir que nuestras aplicaciones web se vean de modo offline, o crear una versión offline de nuestra web. Podemos preguntarnos para qué pensar en lo offline cuando todo el mundo está conectado a todas horas, pues por ejemplo para versiones para móviles, que no siempre se está 100% conectado.

HTML5 permite indicar qué elementos de nuestra web se pueden ver offline o mostrar una página offline en caso de que se acceda a ella. Su uso es bastante sencillo y no nos llevará mucho tiempo.

Lo primero es indicar el manifiesto:

El manifiesto será un fichero que contendrá la información sobre los ficheros cacheables, la página a mostrar offline o contenidos no cacheables. Para que el navegador lo entienda habrá que indicar su MIME type:

AddType text/cache-manifest manifest

Luego habrá que indicar en el fichero que es un manifiesto añadiendo CACHE MANIFEST a la primera línea y luego indicando los ficheros cacheables, la página offline o los contenidos no cacheables:

CACHE MANIFEST
# v1
# Contenido cacheable
pagina.html
pagina.css
pagina.js
pagina.png
# Pagina offline
FALLBACK: / /estoy-desconectado.html
# Paginas dinamicas no cacheables
NETWORK: /path/*

Si la aplicación ha cambiado y necesitamos que el navegador lo refresque, deberemos modificar el fichero, por ejemplo cambiando el número de versión. El fichero .manifiest también puede ser cacheable (mediante htaccess, por ejemplo), ya que el navegador intentará acceder a él siempre que se acceda a la página.

No hay que olvidarse de la API del cache, el cual nos puede aportar mucho en nuestro desarrollo, sobre todo para detectar si el navegador está online u offline:

window.navigator.onLine

Offline Apps with Application Cache: Quickstart, Tips, and Deep Dive

|

Scaling an AWS infrastructure – Tools and Patterns

ByLuis

This is a guest post by Frédéric Faure (architect at Ysance), you can follow him on twitter. How do you scale an AWS (Amazon Web Services) infrastructure? This article will give you a detailed reply in two parts: the tools you can use to make the most of Amazon’s dynamic approach, and the architectural model you should adopt for a scalable infrastr …

Post original

| |

Frame: Modular CSS Framework

ByLuis

Frame is a modular CSS framework that supports: Layout, Typography, Forms, Code, Table, Reset, and Print styling. It is HTML5 compatible, and provides default styles and support for HTML5 elements. Frame is accompanied by an online tool that allows you to easily generate your own build (in case you don’t need to use all the features). …

Post original

|

Designing Web Applications for Scalability

ByLuis

I can’t even count the number of times that I’ve heard this phrase: “don’t worry about scaling your web application, worry about visitor (or customer) acquisition.” My response to this is always that you don’t need to choose one or the other, you can do both! In this post, I’m going to go over some of the strategies I’ve used to architect web appli …

Post original

Qué debería tener un proyecto web Open Source

ByLuis

El uso de herramientas web open source es muy frecuente tanto en proyectos personales como profesionales. Existen alternativas de código abierto para casi todo lo que podemos necesitar: blogs, CMS, gestión de proyectos, galerías de imágenes, … Desgraciadamente, algunas veces estos proyectos open source no son demasiado “buenos” y trabajar con ellos puede ser un verdader suplicio.

Quizás hablo desde la desesperación que sufro últimamente por tener que lidiar con el desarrollo de otros, pero me gustaría compartir una serie de aspectos que debería tener un proyecto web open source, sobre todo aquellos que ya tienen unos cuantos años, lógicamente, sin desmerecer el trabajo altruista de nadie.

  • Buena documentación: imprescindible, ya sea para el usuario como para el desarrollador.
  • MVC: bueno, cualquier proyecto debería seguir esta arquitectura, pero en el caso de un proyecto open source en el que cualquiera puede echar mano al código, se convierte en algo absolutamente necesario ya que normalmente se requiere una personalización y si se ha de tocar el core para realizar los cambios necesarios, mal vamos. Además, el MVC te permite quitar las odiosas tablas que te encuentras en muchos proyectos.
  • Plugins: el proyecto deberá permitir que otros añadan funcionalidades a tu código. El éxito de un proyecto open source depende de la comunidad, y es la comunidad la que se suele encargar de los plugins. En versiones iniciales es posible que esta funcionalidad no exista, pero debería ser una futura implementación.
  • Themes: para proyectos de CMS, blogs o con frontend público, siempre viene bien tener una lista de themes donde poder elegir y diferenciar tu aplicación de otras similares. Además, también es un origen de colaboraciones por parte de la comunidad (al igual que los plugins) y existen numerosas webs o empresas que ofrecen themes de pago, lo cual aporta negocio e interés para los usuarios/desarrolladores.
  • I18N: aunque muchos estamos acostumbrados al inglés, es necesario que el proyecto permita la internacionalización para que existan versiones en diferentes idiomas; a todo el mundo le gusta usar las aplicaciones en su propio idioma.
  • Comunidad: el Santo Grial, si tienes comunidad, tendrás éxito (o casi). Creo que esto debe ser lo más complicado de obtener, porque en parte no depende de tí, depende del gusto de los otros desarrolladores, por eso, quizás, los puntos anteriores sean tan importantes.
  • Foro: aunque algunos crean que los foros están obsoletos, no hay nada más utilizado y necesario que un foro para resolver dudas, sobre todo si existe un foro mayoritario y no tienes que buscar en otros 100, y más importante aún, que las respuestas las ofrezcan, entre otros, los desarrolladores del proyecto open source.
  • Gestor de errores: da igual si es Trac, Bugzilla u otro similar. El problema de todo proyecto es la detección, corrección y seguimiento de errores, si se ofrece una herramienta para que la comunidad se involucre en esta fase el proyecto irá mucho mejor.
  • Gestor de versiones: SVN, git o similares, para que la gente se pueda descargar las últimas modificaciones
  • API: al igual que los plugins, permite que otros interactuen con tu aplicación, sobre todo desde otras aplicaciones diferentes, por lo que se añade riqueza al proyecto.
  • Código documentado: aunque exista una documentación del uso de las funciones “públicas”, siempre viene bien tener la documentación de core.
  • Sencillez: por favor, que para crear un plugin, módulo o componente no sea necesario crear 20 archivos y 30 directorios
  • Estándares: si todos vamos a nuestra bola, al final habrá que aprender 100 métodos distintos, siempre es mejor seguir los eśtandares y no volver loco al personal. Por ejemplo OAuth, no te crees tu propio método de autenticación porque si la gente lo necesita usar le causarás un inconveniente, y si no lo necesita usar se echará para atrás y cambiará de opinión porque no le apetecerá usarlo.
  • Interacción con otras aplicaciones: en el punto en el que nos encontramos es absurdo pensar únicamente en nuestra aplicación, ahora es necesario que todo se conecte con todo, no nos olvidemos de los archifamosos Google, Facebook y Twitter

Actualizado desde aquí

  • Administración: existe algunos proyectos que van por ficheros de configuración, lo cual no quiere decir que sea difícil de administrar, pero no todos los usuarios son avanzados y hay que poner las cosas fáciles a la gente.
  • Instalador: como bien dice Chema un instalador sencillo y paso a paso puede ser fundamental para el éxito del proyecto, ya que si la instalación es complicada, probablemente el usuario no avance y descarte usar nuestro proyecto.

No son nuevas verdades, pero aunque parezca mentira en muchos proyectos que he visto algunos puntos brillan por su ausencia y en otros se hace justamente lo contrario

API de Open Graph de Facebook

ByLuis

Si el otro día salía Open Graph de Facebook, ahora hay que ponerse a hacer aplicaciones para hacer uso de esta API, porque nos guste o no, Facebook nos puede aportar mucho a nuestra aplicación.

La verdad es que la API es muy sencilla: llamada http que devuelve JSON. Siendo la URL de la llamada de esta forma:

https://graph.facebook.com/ID[/CONNECTION_TYPE]

Lo bueno es que el ID puede ser cualquiera: un usuario, una página, un status, una aplicación, … Y luego se le puede añadir el tipo de conexión para obtener los amigos, los vídeos, … de un usuario.

Facebook Graph API