Albert Lanchas nos ofrece un script que me ha gustado bastante en el que se muestran ‘bocadillos’ con imágenes dentro. El bocadillo se adapta al tamaño de la imagen y su aspecto se puede cambiar mediante CSS.
Es necesario tener instalado prototype para su funcionamiento, y su uso es bastante sencillo, incluir el script, la librerÃa prototype, la css e incluir la siguiente lÃnea para que funcione:
Hoy toca realizar conexiones con el servidor usando llamadas autenticadas. Para eso usaremos JWT (JSON Web Token), que viene a ser el envío de un token en cada llamada que necesita autenticación. El token está formado por tres cadenas codificadas en base64 y separadas por un punto (header.payload.signature). En el payload se envía toda la info que queramos, pero sin pasarse porque el token no debería ser muy largo y sobre todo sin enviar información sensible, porque el token no está encriptado, es por ello que la comunicación navegador/servidor debe ser mediante HTTPS. Si quieres una explicación más detallada, aquí te lo explican mejor.
En el payload vamos a guardar varios claims, entre ellos el username y un uuid que usaremos para validar que el usuario es correcto. JWT asegura que el token es válido, pero no viene mal añadir cierta seguridad. Cuando el usuario se loguea un nuevo uuid es generado, por lo que se comprobará si coinciden para el username enviado.
Ya tenemos la explicación teórica, ahora vamos con la parte de programación, primero la parte servidor y luego el frontend.
Lo primero que tenemos que hacer es añadir un nuevo plugin a hapi.js que se encargue de la autenticación, registrando un nuevo strategy a server.auth que use JWT. El plugin hapi-auth-jwt2 se encargará de toda la autenticación JWT y añadiremos una capa extra de validación comprobando que el username y el uuid coinciden.
Y por último añadimos una nueva ruta para autenticar (login) el usuario, comprobamos que el usuario y la contraseña coinciden, y si es así, creamos un uuid que guardamos en la bd y generamos el JWT y lo enviamos en la cabecera Authorization:
Vale, ya tenemos la parte del servidor, ahora la parte del frontend. Primero es añadir las rutas para /login, /account y /logout. He añadido un meta que indica si la ruta tiene que ser obligatoriamente autenticada, obligatoriamente no autenticada o como sea. Para ello, para cada ruta comprobará si el JWT token está almacenado o no y según el meta redirigirá a home o continuará:
Para gestionar el almacenamiento en el navegador en vez de cookies vamos a usar sessionStorage y localStorage para guardar el token JWT. Como el formulario de login permite recordar la sesión, vamos a usar ambos storages. Si no se recuerda usaremos sessionStorage, que se borrará cuando se cierra el navegador, en caso contrario usaremos localStorage.
import Config from'@/js/config';
/**
* API methods for sesion/local storage.
* Depending on `this.session` it saves only on `sessionStorage` or also in `localStorage`
*
* @since v0.8.0
*/classstorage{
/**
* Constructor
*
* @param {boolean} session If stored only in session
*/constructor( session = false ) {
this.session = session;
}
/**
* It saves the token in the session (and local storage is this.session === false),
*
* @param {strig} token JWT token
*/
setJWTToken( token ) {
sessionStorage.setItem( Config.jwt.storageKey, token );
if ( ! this.session ) {
localStorage.setItem( Config.jwt.storageKey, token );
}
}
/**
* It gets a value from session storage or in local if session = false
*
* @returns {string}
*/
getJWTToken() {
const sessionValue = sessionStorage.getItem( Config.jwt.storageKey );
if ( sessionValue ) {
return sessionValue;
}
if ( ! this.session ) {
const storedValue = localStorage.getItem( Config.jwt.storageKey );
return storedValue;
}
returnnull;
}
/**
* Removes JWT token from session and local storage
*/
removeJWTToken() {
sessionStorage.removeItem( Config.jwt.storageKey );
localStorage.removeItem( Config.jwt.storageKey );
}
}
exportdefault storage;
También hemos creado una librería para tratar las llamadas a la API. Hay dos métodos, uno para autenticar el usuario (login) que mirará la cabecera Authorization, y otro método que obtiene los datos del usuario actual realizando una llamada autenticada enviando el JWT token en la cabecera Authorization:
import Config from'@/js/config';
import Storage from'@/js/utils/storage';
/**
* API backend methods
*
* @since 0.8.0
*/classapiFetch{
/**
* Authenticate an user, if ok, JWT token is sent by the server in Authorization header
*
* @param {string} username User name
* @param {string} password Password
*
* @returns {Promise}
*/
auth( username, password ) {
return fetch( Config.api.user.auth, {
method: 'POST',
body: JSON.stringify(
{ username, password }
),
mode: 'cors',
} ).then( response => {
const auth = response.headers.get( 'Authorization' );
if ( auth ) {
return {
response: true,
token: auth,
};
}
return {
response: false,
message: 'Username or password not valid',
};
} );
}
getUser( username ) {
return fetch( `${ Config.api.user.get }${ username }`, {
method: 'GET',
headers: {
Authorization: new Storage().getJWTToken(),
},
} ).then( response => response.json() );
}
}
exportdefault apiFetch;
Ahora solo faltan los controladores para login, account y logout. Login realizar la llamada al servidor y si se obtiene el JWT se guarda:
<template><sectionclass="section"><divclass="container"><h1class="title">
Login
</h1><divv-if="error"class="columns is-centered has-margin-bottom-2"
><b-notificationclass="column is-7-tablet is-6-desktop is-5-widescreen"type="is-danger"has-iconaria-close-label="Close notification"role="alert"size="is-small "
>
{{ error }}
</b-notification></div></div><divclass="container"><divclass="columns is-centered"><divclass="column is-5-tablet is-4-desktop is-3-widescreen has-background-light login-form"><b-fieldlabel="Username"><b-inputv-model="username"value=""maxlength="30"icon="account-circle-outline"
/></b-field><b-fieldlabel="Password"><b-inputv-model="password"value=""type="password"icon="lock-outline"
/></b-field><divclass="field"><b-checkboxv-model="remember">
Remember me
</b-checkbox></div><divclass="has-text-right"><b-buttontype="is-primary"
@click="submit"
>
Log in
</b-button></div></div></div></div></section></template><script>import ApiFectch from'@/js/utils/api';
import Storage from'@/js/utils/storage';
exportdefault {
name: 'Login',
// Form data and error messages if login fails
data() {
return {
username: '',
password: '',
remember: false,
error: '',
};
},
methods: {
// It logs in, using the backend API for authenticate the user data.// If user logs in, it saves the JWT token in the browser. If not, shows error message.
submit: function() {
const api = new ApiFectch();
api.auth( this.username, this.password )
.then( response => {
const storage = new Storage( ! this.remember );
if ( !! response.response && !! response.token ) {
storage.setJWTToken( response.token );
this.error = false;
// `go` refreshes the page, so user data is updatedthis.$router.go( '/' );
} else {
storage.removeJWTToken();
this.error = response.message;
}
} );
},
},
};
</script><stylelang="scss"scoped>.login-form {
border-radius: 4px;
}
</style>
Logout borra los datos JWT del navegador y redirige a home:
<template><sectionclass="hero is-medium is-primary is-bold"><divclass="hero-body"><divclass="container has-text-centered"><h1class="title">
{{ message }}
</h1><h2class="subtitle">
Miss you 💛
</h2></div></div></section></template><script>import User from'@/js/utils/user';
exportdefault {
name: 'Logout',
// Dummy data
data() {
return {
message: 'Bye',
};
},
// After being created it logs out and go to home
created() {
new User().logout();
// `go` instead of `push` because refreshing the page updates the user data// Maybe using vuex is a better way to do it, or not...this.$router.go( '/' );
},
};
</script>
Y Account recupera los datos del usuario una vez que ha creado el controlador:
<template><divid="account"><sectionclass="hero is-primary is-bold"><divclass="hero-body"><divclass="has-text-centered"><h1class="title">
{{ message }}
</h1><h2class="subtitle">
Your data
</h2></div></div></section><sectionclass="section"><divclass="container"><divclass="tile is-ancestor"><divclass="tile is-parent"><pclass="tile is-child notification">
Some content
</p></div><divclass="tile is-8 is-parent"><divclass="tile is-child notification is-info"><ulid="data"><liv-for="( value, key ) in user":key="key"
>
{{ key }} : {{ value }}
</li></ul></div></div></div></div></section></div></template><script>// Dummy componentimport ApiFectch from'@/js/utils/api';
import User from'@/js/utils/user';
exportdefault {
name: 'Account',
data() {
return {
message: 'Account',
user: {},
};
},
created() {
const user = new User().getCurrentUser();
new ApiFectch().getUser( user.username )
.then( response =>this.user = response );
},
};
</script>
Según cuenta el autor, dice que hay una diferencia entre ser un buen diseñador web y un gran diseñador web, que es tomar atajos para hacer más sencillo tu trabajo sin que repercuta en la calidad. Por eso nos da una serie de consejos o trucos a seguir:
Planificación: aunque parece algo obvio, suele ser algo que no se lleva a cabo.
Hazlo a mano: yo no podrÃa estar más de acuerdo con este consejo. Existen aplicaciones muy buenas que te crean el código HTML sin tener que escribirlo uno, pero hacerlo tú mismo es algo que te va a dar mayor control sobre el diseño. Con un editor normal que te coloree el código debe ser más que suficiente.
Hojas de estilo, enlazar o importar: hay dos formas de importar un CSS y no todos los navegadores reconocen las dos formas, por ello se puede usar ambas para que navegadores modernos y antiguos carguen el CSS.
Usar gradientes como fondo con cuidado: el uso de imágenes como fondo de pantalla es algo sobre lo que se puede y debe tener mucho control, se puede hacer un degradado vertical de ancho 1px y luego repetirlo solo en el eje x, y que el color de fondo sea el color en que finaliza el gradiente. Yo añadirÃa que cuidado con los gradientes, ahora están muy de moda, pero tampoco se debe abusar de ellos.
Comentarios: imprescindibles para cualquier tipo de desarrollo, ya sea para una aplicación en .NET o para una página web. Otra cosa es que lo hagamos siempre.
Usa simples scripts PHP: no es necesario ser un experto en PHP, pero si tu servidor lo admite, úsalo, sobre todo para incluir trozos de HTML que sean muy utilizados, como por ejemplo el código que crea el menú.
Dimensiona las fuentes con em: a los diseñadores les suele gustar usar px porque se ajusta exactamente al tamaño que quieren, pero el problema es que, por ejemplo, IE no redimensiona las fuentes definidas con px con el consiguiente problema de accesibilidad para los lectores con discapacidad.
Hack en IE del modelo de caja: quizás no os haya pasado, pero IE tiene un bug con el tamaño de una capa cuando se usa width y margin, padding o border. Esto se soluciona usando el guión bajo delante del estilo (_margin), que IE reconocerá como el propio estilo, mientras que los otros navegadores lo ignorarán. No recomiendo seguir haciendo esto, porque con la nueva versión de IE podrÃais tener problemas ya que se ajusta más a los estándares.
Espacio en los formularios: los form aunque no se vean tienen márgenes, cuando crees uno, no olvides quitarles el margen superior e inferior.
Testea: imprescindible, sobre todo para intentar conseguir que funcione en casi todos los navegadores.
Formato de imágenes: usa GIF para imágenes con colores planos y JPEG para imagenes tipo fotografÃa, aunque deberÃas usar PNG en ambos casos, ya que funciona tanto para colores planos como para tipo fotografia, el problema es que IE no admite el canal alpha, hay que esperar a IE7 para que lo podamos usar.
Atributos alt y title: para que la descripción de las imágenes o enlaces aparezcan correctamente en los dispositivos móviles.
Orden de las pseudoclases: como ya explicamos en esta entrada.
Lenguaje semántico: separa el contenido de la apariencia, si eliminamos la css de una página se deberÃa ver correctamente.
Favicons: los iconos que aparecen en los favoritos o en las pestañas, algo sencillo que representa a nuestra web.
Usa máyusculas mediante CSS: cuando quieras escribir un texto completamente en mayúsculas usa text-transform en vez de escribirlo tú directamente en mayúsculas.
Escribe el texto alrededor de las imagenes: algo ya comentado en esta entrada.
Usa UTF-8: no todo el mundo tiene tu idioma o tu juego de caracteres, vuelve a leer esta entrada para obtener más información.
Estilos para impresora: crea estilos especÃficos para impresoras (media=”print”)
Aprende de otros: para eso nada mejore que CSSMania.
Elements of Design es una galerÃa de elementos contenidos en páginas web que nos puede ayudar a diseñar partes de la página y añadirlas al diseño general. Es como CSSMania pero en vez de diseños completos, enfocado únicamente a elementos.
Podremos encontrar diseños de formularios para comentarios de blogs, comentarios de blogs, calendarios, código, iconos, texto entrecomillado, formularios de registro, cajas de búsqueda y tipologÃa de cabeceras. Elements of Design
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
Interesante script que usa canvas para detectar rostros en las fotografías. Se basa en openCV y en el post de John Resig para evitar un captcha.
Permite la opción de reconocer una cara o varias caras, este último lo he probado con una foto y no me ha funcionado, pero como bien dice el autor, aún tiene que mejorar más el script.
Interesante opción para servicios como Facebook o Flickr para sus opciones de asociar elementos (usuarios, comentarios, …) a las fotografías. También es útil para avisar de que no se ha subido una cara cuando alguien cambia de avatar. Face detection in javascript + canvas
Vía / @rafabayona
Google ofrece sus aplicaciones GMail, Calendar, GTalk y Page Creator a las empresas para que puedan usarlas desde sus propios dominios.
Esta oferta amplia la anterior de GMail for your Domain, la cual ha conseguido que Google ya tenga miles de dominios registrados.
Estas aplicaciones serán accesibles desde un panel de control y se podrá configurar la interfaz y el color, a parte de administrar los usuarios, los alias y las listas de distribución. Una futura versión premium tendrá más capacidad de almacenamiento.
VÃa / CNet News