HAProxy es un proxy gratuito, con balanceo de carga y que soporta decenas de miles de peticiones. Además de tener un gran rendimiento, permite tener un control de concurrencia, esencial cuando tenemos demasiadas peticiones que nuestro sistema no puede soportar, y en vez de saturar el sistema y dar un mal servicio a todo el mundo, podemos limitar el número de peticiones para que al menos una parte de los usuarios sí reciban el servicio adecuado.
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
No conocía esta tecnología de Google que permite crear 3D en la web. O3D pretende ser el estándar para desarrollo 3D en la web. Los ejemplos que ofrecen son verdaderamente asombrosos, y para usarlo tan sólo es necesario instalar un plugin.
Para los que nos dedicamos al desarrollo web no creo que esto nos vaya a ser de utilidad, aunque nunca se sabe. Si estás interesado, un bueno punto de comienzo es el tutorial que os paso.
An Introduction to Google’s O3D
Sphinx (SQL Phrase Index) es un motor que permite buscar texto. Normalmente es un motor de búsqueda independiente, que provee de forma rápida y eficiente resultados relevantes a otras aplicaciones. Está diseñado para ser integrado con MySQL y lenguajes de programación (actualmente PHP). Los datos se pueden recuperar mediante conexión directa a MySQL o mediante XMLs.
Dispone de cuatro utilidades: indexer para crear Ãndeces de texto, search para buscar desde la lÃnea de comandos, searchd es un demonio que busca en los textos desde aplicaciones externas y sphinxapi un API para lenguajes de programación (PHP).
Entre las caracterÃsticas que ofrece nos encontramos con lo siguiente:
Alta velocidad de indexación (+10Mb/s)
Alta velocidad de búsqueda (0.1 s. en 2-4 Gb de texto)
Alta escalabilidad
Soporte para búsquedas distribuidas
Soporte para MySQL nativo (admite tablas MyISAM y InnoDB)
La verdad es que Firefox4 está de lujo, y las demos que ofrece Mozilla son increíbles. De una de ellas he sacado cómo hacer clipping en vídeos usando HTML5 y la posibilidad de incrustar SVG (sólo funciona en Firefox4).
El método es sencillo, tengo un SVG que muestra el contorno y los botones de play y pausa, además tiene un clipPath que se usará para el estilo clip-path del vídeo:
SVG
Vídeo
Javascript
var play = document.getElementById('play');
var pause = document.getElementById('pause');
var video = document.getElementById('video');
play.addEventListener('click', function() {
play.style.display = 'none';
pause.style.display = 'block';
video.play();
}, true);
pause.addEventListener('click', function() {
play.style.display = 'block';
pause.style.display = 'none';
video.pause();
}, true);
video.addEventListener("ended", function() {
play.style.display = 'block';
pause.style.display = 'none';
video.pause();
}, true);
El vídeo es el mismo que el de la demo de Mozilla, he puesto el borde semi-transparente para que se vea el clipping como va.
Hierarchical-Model-View-Controller (HMVC) es una variante del MVC que se forma mediante una colección de estos, siendo cada MVC independiente de los otros, y siendo un aspecto importante la reutilización de código, por lo que la localización física de los MVC no es importante. El HMVC es muy efectivo a la hora de testear módulos de la aplicación independientes, y una buena opción para escalar nuestra aplicación.
El tutorial nos muestra cómo usar Kohana para llevar a cabo una aplicación que implemente HMVC. Está claro que una aplicación así puede ser algo más difícil de diseñar y que no siempre puede que necesitemos este grado de escalabilidad.
Buena serie de consejos a tener en cuenta cuando desarrollamos nuestro sistema de login. Algunos son ya conocidos, pero no está mal recordarlos:
Logitud de la contraseña y nombre de usuario: tiene que tener mínimo 6-8 caracteres.
Encriptar la contraseña: aunque casi todo el mundo usa MD5 o SHA-1, no está mal del todo usar SHA-2 (disponible en PHP5), ya que las anteriores ya no son tan seguras como hace tiempo.
Añade una semilla a la contraseña: cuando encriptes la contraseña es recomendable añadirle un texto para que el hash sea mas seguro.
No uses nombres sencillos para el administrador: evita usar nombres como “admin”, “root”, …
Registra los intentos de login: así se podrá detectar cuando estamos siendo atacados.
Maneja los errores: cuando se produce un login fallido, o evita que se produzca un error, o muestra un error personalizado, no muestres errores de código que puedan dar pistas al atacante.
Filtra la entrada: filtra lo que el usuario meta en su usuario para evitar inyecciones de código y no compruebes si la contraseña es correcta mediante SQL.
Usa LIMIT o WHERE 1: es importante para evitar comprometer muchas cuentas si sufrimos un ataque.
Usa nonce: nonce es un número único para la sesión, así nos aseguramos de que no se realicen ataques de fuerza bruta usando diccionario.
Usa sólo $_POST: $_GET es más sencillo de usar que $_POST, aunque no quita que usando $_POST no nos encontremos con problemas.
Cuentas MySQL: utiliza un usuario con permiso de select para realizar el login, así, si rompen tu seguridad, no podrán hacer deletes, updates o inserts.
Auto logout: Si quieres darle mayor seguridad, desconecta al usuario automáticamente pasado un cierto tiempo de inactividad. Aunque desde el punto de vista de la usabilidad no es muy recomendable.
Bloque la cuenta: si se han intentado varios logins consecutivos y han sido fallidos, se debería bloquear la cuenta.
disculpa que te corrija, pero un proxy no limita el número de usuarios sino que limita el número de conexiones a la base de datos y de ejecuciones de, por ejemplo, php, mostrando una versión “precargada” de la web.
disculpa que te corrija, pero un proxy no limita el número de usuarios sino que limita el número de conexiones a la base de datos y de ejecuciones de, por ejemplo, php, mostrando una versión “precargada” de la web.
Un saludo.
Hola Alejandro, yo no he dicho que el proxy limite el número de usuarios, sino el número de peticiones (tal y como dices tú) para que asà no todos los usuarios se queden sin servicio, sino que al menos algunos puedan acceder.
disculpa que te corrija, pero un proxy no limita el número de usuarios sino que limita el número de conexiones a la base de datos y de ejecuciones de, por ejemplo, php, mostrando una versión “precargada” de la web.
Un saludo.
marketing en internet
disculpa que te corrija, pero un proxy no limita el número de usuarios sino que limita el número de conexiones a la base de datos y de ejecuciones de, por ejemplo, php, mostrando una versión “precargada” de la web.
Un saludo.
Hola Alejandro, yo no he dicho que el proxy limite el número de usuarios, sino el número de peticiones (tal y como dices tú) para que asà no todos los usuarios se queden sin servicio, sino que al menos algunos puedan acceder.
Saludos