Appcelerator: otra forma de realizar aplicaciones web

ByLuis January 15, 2008

Appcelerator es una plataforma open source que cambia la forma de realizar aplicaciones web. EstÃ¡ basado en una arquitectura basada en mensajes, lo que quiere decir que toda la plataforma estÃ¡ manejada por mensajes, los cuales son tamaÃ±a pequeÃ±o. Los elementos HTML pueden enviar o recibir mensajes para cambiar su aspecto o para solicitar datos al Appcelerator Service, el cual es el responsable de gestionar todos los mensajes de la aplicaciÃ³n a/hasta los clientes.

Las aplicaciones usan Ajax y DHTML estÃ¡ndar para realizar las RIA, aunque dicen que sin Javascript, algo que no llego a comprenderles muy bien, porque lÃ³gicamente si usa Javascript, quizÃ¡s se refiera a que el desarrollador no necesita usar Javascript porque se implementa directamente.
Appcelerator ofrece una separaciÃ³n clara entre la parte lÃ³gica y la de presentaciÃ³n, usando servicios SOA para ello, por lo que es posible crear clientes para Java, PHP, .NET, Ruby y Python.
Appcelerator
Gracias diarioTHC por el aviso

Desarrollo web | Javascript

Clipping de vídeo usando HTML5 y SVG en Firefox4

ByLuis March 23, 2011March 23, 2011

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.

Demo

Vía / Project London Trailer

Desarrollo web

Recursos para un sitio compatible con navegadores

ByLuis October 23, 2007

Uno de los mayores problemas con los que nos encontramos cuando estamos desarrollando una aplicaciÃ³n web es la compatibilidad con los diferentes navegadores, bueno, realmente la compatibilidad de estos navegadores con los estÃ¡ndares.

Para ayudarnos en esta lucha, nada mejor que esta serie de recursos:

Cross Browser CSS For Your Site: una guÃa para realizar CSS compatible con los diferentes navegadores, grandes consejos con ejemplos, no teorÃa.
Starting With CSS: Revisited: cada navegador tiene estilos por defecto para las etiquetas HTML, siendo estos algo diferentes entre ellos. Elimina el margin y el padding para empezar con todos los navegadores del mismo modo.
undohtml.css: similar a la tÃ©cnica anterior.
Two CSS Hacks For Identical Pages: dos consejos que podemos usar y un aviso de cÃ³mo empezar a escribir tu cÃ³digo.
CSS Hacks & Issues: una serie de consejos y trucos para librarse de los quirks de Internet Explorer.
Box Model Hack: hack para dibujar correctamente el modelo de caja en IE 5 y 5.5.
Eric Meyer On CSS: consejos para usar trucos con los navegadores y ocultar estilos.
/* Position Is Everything */: necesario para aquellos que quieran desarrollar su layout.
glish.com : CSS layout techniques: ejemplos de layouts de 3 columnas, 2 columnas y modelos fluidos.
100 Percent Cross Browser, Pure CSS Layouts: otro lugar donde encontrar layouts CSS.
Rendering Mode and Doctype Switching: esta pÃ¡gina te enseÃ±a que DOCTYPE usar para usar el “standards mode”.
Activating the Right Layout Mode Using the Doctype Declaration: tabla con una relaciÃ³n de los navegadores y el tratamiento que le dan al doctype.
In Search of the Holy Grail: creaciÃ³n de layouts.
Litmus Labs: CSSVista: aplicaciÃ³n que permite modificar tus CSS en Firefox y en IE.
Browser Shots: herramienta online que te devuelve pantallazos de una pÃ¡gina vista en diferentes navegadores.
IE NetRenderer: lo mismo pero para diferentes versiones de IE.

Designing For Every Browser: How To Make Your Site Fully Cross Browser Compatible

VÃa / dzone

Desarrollo web

10 razones para seguir estrategia Open Source

ByLuis September 10, 2007

Actualmente algunas empresas son poco partidarias de utilizar herramientas open source a la hora de realizar sus proyectos. AquÃ os paso algunas razones que nos pueden animar a hacerlo, aunque claro, esto es segÃºn gustos y habrÃ¡ otras razones que invaliden las que se indican.

Disminuir la dependencia a vendedores de cÃ³digo propietario: esto suele ser debido a la necesidad de actualizar la versiÃ³n del producto, esperando mejoras o nuevas funcionalidades, ocasionando en algunos casos un gasto de dinero y tiempo importante.
No hay necesidad de presupuestar el coste de mantenimiento de software y de personal encargado: el gasto que suponen las licencias de software y el salario de personal conocedor de esas herramientas suele ser bastante elevado, incrementando asÃ los costes del proyecto y repercutiendo en los beneficios.
Acceso a mÃ¡s herramientas: se puede acceder a un casi ilimitado nÃºmero de herramientas (desarrollo, testing, CMS, seguridad, …), sin necesidad de solicitar permiso para obtenerlo debido a su coste.
PruÃ©balo antes de comprarlo: aunque muchas de las herramientas propietarias si ofrecen versiones Trial o gratuitas para desarrollo, sÃ que es imposible a veces ver cÃ³mo funciona un producto sin tener que comprarlo antes.
Soporte por parte de una comunidad de usuarios: esto es algo que a las empresas les suele echar para atrÃ¡s, el no tener un soporte oficial. Como desarrollador puedo asegurar que normalmente el soporte lo da Google y no el soporte oficial, del cual el 90% de las veces no se utiliza.
Acceso al cÃ³digo y la posibilidad de modificarlo segÃºn tus necesidades: algo bastante tÃpico es tener que esperar a una nueva versiÃ³n o tener que comprar una versiÃ³n actualizada de un producto para conseguir una funcionalidad necesitada. Si dispones del cÃ³digo es posible que puedas modificarlo a tu gusto. Algo parecido hizo Google con MySQL.
Poder de negociaciÃ³n con vendedores de software propietario: con esta no estoy muy conforme, pero bueno, quizÃ¡s nunca se me haya el caso, como dice, de poder obtener mejores condiciones de Microsoft si tienes Ubuntu instalado en 20 ordenadores como experiencia piloto.
No hay exceso de caracterÃsticas inÃºtiles: en los proyectos open source, las nuevas funcionalidades suelen venir dadas por las necesidades de los usuarios, no por las ideas de un departamento de desarrollo o marketing.
MÃ¡s seguridad: algo que crea mucha controversia, pero estudios como el de Trend Micro muestra que el open source es mÃ¡s seguro.
SoluciÃ³n de errores y nuevas implementaciones con mÃ¡s rapidez: en algunos casos los errores se solucionan mucho antes incluso de que lo detecten los usuarios.

10 Reasons why you need an Open Source Strategy

VÃa / OpenSourceCommunity.org

Desarrollo web

Qué debería tener un proyecto web Open Source

ByLuis June 1, 2010June 1, 2010

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

Desarrollo web

Snipplr: trozos de código

ByLuis September 25, 2006

A todos nos pasa que nos gusta reutilizar (copy/paste) aquellas trozos de cÃ³digo (snippet) que hemos creado en algÃºn proyecto anterior y que no nos apetece volver a pensar cÃ³mo hacerlo. En vez de tener que buscar entre todo el cÃ³digo que tenemos y pasarse todo el tiempo diciendo “recuerdo haber hecho esto en tal sitio”, podemos usar Snipplr para guardar nuestros propios snippets o para usar los que comparten otros usuarios, organizados por lenguaje de programaciÃ³n y por tags.
Snipplr
VÃa / Criterion

Desarrollo web

Retícula para tus diseños web

ByLuis July 19, 2006

Veo en Intenta un truco para usar una rÃ©ticula cuando diseÃ±amos una pÃ¡gina web, para que todo quede cuadrado y alienado como queremos. Es tan sencillo como incluir un estilo para el body que muestre como imagen de fondo una retÃcula, asÃ podremos ver como cuadra o no nuestro diseÃ±o.

Si ya lo usas combinado con MeasureIt, ya no tienes excusas para realizar diseÃ±os milimÃ©tricos.
VÃa / Intenta

Similar Posts