Consejos para jQuery

ByLuis

Últimamente hablo mucho de jQuery, y no es para menos, ya que este framework de Javascript es muy bueno y la gente realiza grandes plugins que nos ayudan en nuestros desarrollos. En este caso se trata de varios consejos que nos serán muy útiles a la hora de desarrollar:

  • Carga la librería desde Google Code
  • Almacena en variables los selectors que vayas a usar en varias ocasiones
  • Evita la manipulación DOM lo máximo que puedas, es mejor realizar una llamada “gorda” que varias pequeñas
  • Usa preferiblemente IDs en vez de nombres de clase cuando realices búsquedas
  • Realiza la captura de eventos correctamente, muchas capturas suele ser ineficiente
  • Usa los nombres de clase para guardar el estado de un objeto
  • Incluso mejor que el anterior, usa el método data() para guardar datos en un objeto
  • Aprende a crear tus propios selectores
  • Usa noConflict() para renombrar el objeto jQuery y no tener problemas con otras librerías
  • Aprende a controlar cuando se cargan las imágenes
  • Usa .lenght en un selector para saber si un objeto existe
  • Añade una clase al objeto HTML para modificar elementos por CSS cuando el documento se haya cargado

Improve your jQuery – 25 excellent tips

Vía / Intenta

Similar Posts

|

Create a Twitter AJAX Button with MooTools, jQuery, or Dojo

ByLuis

There’s nothing like a subtle, slick website widget that effectively uses CSS and JavaScript to enhance the user experience.  Of course widgets like that take many hours to perfect, but it doesn’t take long for that effort to be rewarded with above-average user retention and buzz.  One of the widgets I love is Twitter’s “Follow” button.  Let me sho …

Post original

Codetcha: CAPTCHA resolviendo Javascript

ByLuis

La verdad es que este CAPTCHA es muy friqui, pero es una idea interesante que quizás se pueda utilizar. Se trata de un CAPTCHA que en vez de tener que escribir una palabra, hay que modificar un código Javascript para que no tenga errores y así validar el formulario.
codetcha.png
Para pasar el CAPTCHA hay que eliminar todos los errores, se puede ir viendo si el código es correcto y si no es así, qué errores sigue habiendo. El código de Codetcha se puede usar para clases o ejemplos de Javascript, porque me da la sensación de que no es muy accesible este CAPTCHA.
Aún así la idea se podría sustituir usando matemáticas en vez de Javascript.
Codetcha

jQuery Masonry: encaja capas HTML

ByLuis

Supongo que lo de “encajar capas HTML” no es algo que se entienda muy bien, pero realmente se trata de eso. Este plugin de jQuery coloca las capas HTHL de tal forma que no queden espacios en blanco entre ellas (algo normal cuando se usa el css float).
jquery-layout.png
Hay que tener cuidado, porque aunque nos devuelve un layout sin espacios en blanco, también nos lo da con un orden no muy usable, por lo que es importante no usar este plugin cuando el orden de colocación importa.
jQuery Masonry
Vía / WebAppers

jsPDF: crea PDFs directamente desde Javascript

ByLuis

Interesante javascript que nos permite crear PDFs sin necesidad de aplicaciones en el servidor, sino usando únicamente una librería PDF. Su uso es muy sencillo, devolviendo una URL con Content-type y codificada en Base64:


var doc = new jsPDF();
doc.setFontSize(22);
doc.text(20, 20, 'This is a title');

doc.setFontSize(16);
doc.text(20, 30, 'This is some normal sized text underneath.');	

// Output as Data URI
doc.output('datauri');

A mí en Firefox no me ha funcionado, pero en Chrome sí.

jsPDF

Vía / DZone

Hapi.js + Vue.js modelos mejorados

Hapi.js + Vue.js modelos mejorados

ByLuis

En este caso voy a explicar cómo añadir una ruta en el backend para gestionar usuarios.

Antes de nada vamos a instalar tres paquetes:

  • @hapi/joi para validar los datos de entrada
  • @hapi/boom para mostrar errores HTTP de forma sencilla
  • bcrypt para encriptar la contraseña
npm i @hapi/joi
npm i @hapi/boom
npm i bcrypt

Tendremos que añadir la ruta al manifest de glee

const manifest = {
	server: {
		port: Config.get( '/server/port' ),
	},
	register: {
		plugins: [
			{
				plugin: './api/home',
			},
			{
				plugin: './api/user',
			},
			{
				plugin: './plugins/db',
				options: Config.get( '/db' ),
			},
		],
	},
};

Ahora solo falta crear el controlador para las rutas de usuarios, dos en este caso:

  • GET /user/[user] para recuperar un usuario
  • PUT /user para crear un nuevo usuario

Lógicamente aún no hay nada de autenticación, por lo que cualquiera puede crear un usuario realizando una llamada PUT a la URL indicando userName, email y password.

Para comprobar la validez de los datos introducidos, usaremos joi. Usando las opciones de la ruta, indicaremos las reglas que deberá cumplir cada parámetro introducido. Así, para recuperar un usuario, se comprobará que user sea string, alfanumérico y que tenga una longitud de 3 a 20 caracteres:

validate: {
	params: {
		user: Joi.string().alphanum().min( 3 ).max( 20 ),
	},
},

Así de fácil.

En el caso de comprobar los datos de entrada de la llamada PUT, en vez de usar params, usaremos payload:

validate: {
	payload: {
		userName: Joi.string().alphanum().min( 3 ).max( 20 ).required(),
		email: Joi.string().email().required(),
		password: Joi.string().min( 8 ).required(),
	},
},

Por último mostrar el código para crear un nuevo usuario. Primero se comprueba si existe un usuario con ese nickname o email. Si es así, se devuelve error usando boom, si no, se genera la contraseña encriptada (aquí no me he molestado mucho en ello, ya lo haré más adelante), y se crea el usuario usando el método create de moongose:

/**
 * Route handler
 *
 * @param {object} request
 * @param {object} h Hapi object
 * @returns {object}
 */
handler: async( request, h ) => { // eslint-disable-line
	try {
		// TODO: Add role
		const user = await User
			.findOne( {
				$or: [
					{ userName: request.payload.username },
					{ email: request.payload.email },
				],
			} )
			.exec();
		if ( user ) {
			return Boom.badData( 'User exists' );
		}
		const password = await bcrypt.hash( request.payload.password, Config.get( '/hash/PASSWORD_HASH' ) );
		const userData = Object.assign( {}, request.payload, { password } );
		const newUser = await User.create( userData );

		return newUser ?
			{
				response: true,
				message: 'User created',
				userId: newUser.id,
			} :
			Boom.boomify( {
				response: false,
				message: 'There was an error during user creation',
			}, { statusCode: 400 } );
	} catch ( error ) {
		return Boom.badImplementation( 'Error', { error } );
	}
},

Como último apunte, he modificado la configuración para que admita ficheros .env con los datos necesarios.

Como siempre te puedes bajar el código aquí

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