Tutoriales de Desarrollo y Diseño Web | Web.Ontuts

Introducción a Backbone.js

Iván Guardado — Tue, 15 May 2012 15:39:24 +0000

Cada vez más, las aplicaciones web tienden a dejar de lado el antigüo modelo de “hago click y espero a que cargue una nueva página” para enfocarse en un modelo más interactivo e instantáneo, en el que las acciones de usuario tienen una respuesta inmediata, imitando así las aplicaciones de escritorio. Como sabrás, para conseguir esto, se necesita delegar el control de nuestra aplicación a Javascript.

En un principio, la simple idea de gestionar una aplicación completa en Javascript nos puede desbordar, pero no te preocupes, ya que existen múltiples frameworks que nos ayudan a llevar a cabo esta tarea, y uno de ellos es Backbone.js.

¿Qué puedo hacer con Backbone.js?

Backbone te permite estructurar tu aplicación mediante modelos (que es la forma de organizar tus datos en objetos), colecciones y vistas, y conecta todo con tu API del servidor a través de una interfaz JSON. Tambien te permite tener vinculado un modelo con su vista de forma sincronizada, así, si cambia una propiedad del modelo, cambiará también su representación en la interfaz.

Eso… ¡y muchas cosas más! Enumero ahora las características más importantes poniendo ejemplos para cada una de ellas.

Backbone.Model

Es el núcleo del framework, ya que es la forma que tienes de organizar los datos con los que va a trabajar tu aplicación. Un modelo puede representar, por ejemplo, la información de una tarea, con sus atributos y métodos, y se define de la siguiente forma:

var Task = Backbone.Model.extend({
    defaults: {
        title: 'Tarea sin título',
        status: 'Open'
    },
    close: function(){
        this.set('status', 'Closed');
    },
    open: function(){
         this.set('status', 'Open');
    }
});

window.mytask = new Task({
    'title': 'Ir al super',
    'text': 'Comprar leche y patatas'
});

En el ejemplo anterior creamos el modelo para una tarea, que tiene dos atributos por defecto (title y status) y dos métodos (close y open). Al crear una instancia de un modelo, le pasamos los valores de inicialización en el constructor, tal como se muestra en el ejemplo.

Para acceder a los valores de los atributos del modelo, no se hace de forma directa, si no que se hace a través del método get():

save

Llama a este método cuando desees guardar el estado actual del modelo en la base de datos. Si es un modelo nuevo, es decir, no se había creado antes en la base de datos, el método enviará una llamada tipo POST a la url encargada de gestionar dicho modelo. En el caso de que el modelo ya exista, se hará una llamada de tipo PUT

var Task = Backbone.Model.extend({
    urlRoot: '/tasks'
});
window.mytask = new Task({title: 'Ir al super', 'text': 'Comprar leche y patatas'});
window.mytask.save();

Hace una llamada AJAX de tipo POST al servidor.

destroy

Envía una llamada AJAX de tipo DELETE al servidor para eliminar el modelo de la base de datos y lanza el evento destroy a través de todo el modelo y colecciones para mantenerlos sincronizados.

validate

Necesitas sobreescribir este método en el modelo si necesitas validar los datos antes de hacer un set o un save. La función recibe por parámetro los nuevos valores de los atributos, y si los datos son correctos, la función no devolverá nada, en caso contrario, puede devolver una cadena de texto con el error, un número de error, o lo que quieras y no se continuará con la ejecución del set o save.

var Task = Backbone.Model.extend({
    validate: function(attrs){
        if(attrs.status !== 'Open' || attrs.status !== 'Closed'){
            return 'Invalid task status!';
        }
    }
});

Backbone.Collection

Una colección es un conjunto ordenados de modelos sobre la que se pueden añadir listeners para eventos como change, add, remove o ejecutar métodos como fetch, que carga la colección desde el servidor. Para definir una colección, se usa igualmente el método extend pero de la clase Backbone.Collection:

var TaskList = Backbone.Collection.extend({
    model: Task,
    url: '/tasklist',
    closed: function(){
        return this.filter(function(task){ return task.get('status') == 'Closed' });
    }
});
window.taskList = new TaskList();

En el código anterior, se crea un colección para modelos de tipo Task, cuya url para manejar la persistencia es /tasklist. Además añade un método propio para filtrar la colección por las tareas cuyo estado es ‘Closed’.

add

Añade un modelo o un array de modelos a la colección. Si has especificado el atributo model puedes directamente añadir los atributos de cada objeto.

Como ves, no es necesario que crees el objeto antes de añadirlo, puedes directamente especificar sus atributos

remove

Elimina un modelo de la colección. Si deseas eliminar todo rastro de dicho modelo, esta es la forma recomendada:

Task.bind("remove", function(){
    this.destroy();
}
var task = new Task();
taskList.add(task);
taskList.remove(task);

Al llamar al método remove de la colección se lanza el evento remove en el modelo sobre que se está eliminando, y luego, desde dicho modelo llamamos al método destroy para que se borre tambien del server (si es lo que queremos).

fetch

Este método se encarga de traer el conjunto de modelos del servidor y cargarlos en la colección, reseteándola. El server debe de encargarse de devolver la colección de los modelos en formato JSON, si estás trabajando sobre una API del servidor antigüa y no puedes generar dicha respuesta, te interesará sobreescribir el método parse

parse

Este método es llamado por Backbone cuando esta necesita convertir una respuesta del servidor en un conjunto de modelos. Por lo tanto, es útil sobreescribir este método si no estás trabjando con la API que Backbone espera por defecto.

Por ejemplo, imagina que el server en lugar de devolver directamente el array con los modelos, devuelve un objeto que contiene más información. Puedes sobreescribir el método para pasarle a backbone cuales son los datos que debe usar.

var TaskList = Backbone.Collection.extend({
    parse: function(response){
        //response es el objeto JSON que devuelve el server
	//y podría, por ejemplo contener otros atributos como:
	//response.status, response.message,...
	return response.models;
    }
});

reset

Este método sirve tanto para limpiar el contenido de la collección, como para reemplazar el contenido por los nuevos modelos especificados por parámetro.

Además de estos métodos, existen muchos más métodos para trabajar con las colecciones, como: push, pop, shift, unshift, sort, pluck, where… Échale un vistazo a la documentación oficial para conocerlos a fondo.

Backbone.View

Las vistas en Backbone tienen la misión de organizar las distintas partes de la interfaz de la aplicación y mantenerlas actualizadas con el modelo. Backbone no hace suposiciones sobre nuestro HTML / CSS ni sobre el sistema de templates que queremos usar, por eso, las vistas en Backbone tienen más que ver con organización que con código. El siguiente ejemplo muestra la típica estructura de una vista:

var TaskView = Backbone.View.extend({
    tagName: "li",
    className: "task",

    initialize: function(){
        this.model.on('change', this.render, this);
    },

    render: function(){
        this.$el.html(_.template($('#taskTemplate').html(),this.model.toJSON()));
	return this;
    },

    events: {
        'click .delete': 'deleteAction'
    },

    deleteAction: function(){
        this.model.destroy();
        return false;
    }
});
var taskView = new TaskView({model: mytask, id: 'task-'+mytask.id});

constructor

El constructor para la vista acepta como en el caso de los modelos y las colecciones, un conjunto de atributos que se fijarán en el objeto. Lo común es especificar el modelo con los datos que van a ser representados y un id único que será usado como atributo en el DOM.

tagName y className

Son los atributos que nos permiten decirle a Backbone cual será el elemento raíz que contendrá la vista, en el caso anterior, se traducirá en:

el y $el

Son los atributos que almacenan la referencia a la raíz HTML de la vista. Siguiendo con el ejemplo, el sería un objeto DOM que representa

. $el es el objeto el encapsulado por jQuery para poder trabajar de forma más cómoda.

initialize

Es el método llamado en el momento de la creación del objeto, en el ejemplo, añadimos un listener para el evento change del modelo vinculado, de forma que cuando cambie un atributo del modelo, se vuelva a renderizar la vista, sin tener que preocuparnos de nada más.

render

Esta función se necesita sobreescribir para especificar como se va a mostrar la vista en la interfaz. Tienes total libertad de hacerlo como quieras, por ejemplo, puedes concatenar todo el contenido HTML en una string para luego añadirlo, o usar document.createElement o cualquier framework que gustes. Lo más aconsejable, es usar un sistema de templating como Mustache.js, Haml-js, Eco o jQuery Templates.

En el ejemplo anterior he usado Underscore.js y para que funcione, necesitas tener una template con el id taskTemplate en tu HTML. Tal que así:

events

Definiendo este atributo podemos especificar los distintos eventos del usuario sobre el DOM que representa la vista. La forma de definir un evento es "evento selector": "callback". Es importante tener en cuenta que el selector solo buscará en los nodos pertenecientes a this.el. En caso de omitir el selector, el evento se aplicará a this.el.

En el ejemplo, definimos el evento de cuando el usuario hace click en el link de Borrar, cuya clase CSS es delete, y le asignamos el callback deleteAction, la cual definimos en la siguiente línea.

Hasta aquí...

Hasta aquí la introducción a Backbone.js, creo que más o menos he listado las cosas más importantes, ¡pero hay más! Échale un vistazo a la documentación original.

¿Qué os ha parecido? ¿Creeis que Backbone.js va a ser un MUST como ya prácticamente lo es ahora jQuery, o conocéis otras librerías que le puedan arrebatar ese privilegio?

Este es el primero de una serie de tutoriales orientados a Backbone.js y desarrollo de aplicaciones en Javascript, así que estate atento, ¡proximamente más y mejor!

En la Conferencia Rails 2011: las conferencias 1/2

Roberto Luis Bisbé — Fri, 15 Jul 2011 15:57:46 +0000

Segundo día: Empiezan las conferencias

Seguimos cubriendo la serie de la conferencia Rails, esta vez ya cubriendo las conferencias en sí, fueron muchas así que intentaré ser conciso:

Introducción y estado de Ruby on Rails

Primeramente, y tras el proceso de inscripción que dio como resultado una camiseta (para todos) y una taza (solo para los más previsores), tomamos asiento en el Florida Park, un sitio interesante situado dentro de ese enorme lugar que es el Parque del Retiro en Madrid, Javier Ramirez nos dio la bienvenida comentando el estado de Rails, y la contribución de la comunidad española a la causa, fue una charla muy interesante que nos permitió ver un poco cómo evolucionaban a la par el framework y los eventos relacionados.

Julian Fischer: hay que actualizarse a la última versión

Tras esta breve introducción al estado de Rails, Julian Fischer nos estuvo hablando, primeramente de cómo vino desde Alemania en moto para darse el paseíllo, y más adelante de cómo migraron sus aplicaciones (y más importante, sus desarrolladores) a rails 3.x. Nos habló de la necesidad de actualizar, de convencernos que tenemos que hacerlo y de convencer a nuestros clientes de tener los productos funcionando con la última versión disponible. También destacó la idea de tener (desde el punto de vista de un jefe de proyectos) a nuestra gente también actualizada (dar opciones a la formación e incentivarla).

CofeeScript con Nicolás Sanguinetti

Tras el cofee-break, una sesión de CofeeScript, impartida por Nicolás Sanguinetti, donde nos comentó las deficiencias de Javascript, y cómo CofeeScript ayudaba a paliarlas, usando una sintaxis más simple, y con varios ejemplos que nos ayudaron a tener una idea en general de la herramienta. Para gente con conocimientos de Javascript, era una de las charlas más recomendable.

How I learned to smell code

La última charla de la mañana se titulaba “How I Learned to Smell Code” que podemos traducir por “Cómo he aprendido a oler el código”, una charla impartida por Renée de Voursney, donde tras explicarnos su trayectoria profesional, nos comentó cómo sus capacidades iban evolucionando desde la universidad (donde tu código no se escribe para ser mantenible), primeros trabajos (donde, pese a mayor control, tu código era apenas reutilizado), hasta llegar a la comunidad Rails, viendo cientos de proyectos, y aprendiendo crear código que fuera usable por el resto de desarrolladores.

Finalmente nos comentó varios puntos a tener en cuenta a la hora de aprender:

Intentar enseñarselo a alguien
Hacer katas (ejercicios de código)
Leer libros (concretamente nos propuso The Pragmatic Programmer y Clean Code: a handbook of agile software craftsmanship)
Tener un hobby, a ser posible que no tenga que ver nada con tu trabajo

Después de comer: introducción a 5 lenguajes diferentes

Tras la comida, la primera sesión de la tarde fue una introducción en poco más de una hora, a 5 lenguajes de programación diferentes, por Sergio Gil: erlang, un lenguaje funcional, orientado a la concurrencia y a la tolerancia a errores, haskell, un lenguaje puramente funcional, con un sistema de tipos interesante, y extremadamente eficiente, common lisp, un lenguaje de programación funcional donde se mezclan indistintamente código y datos, la sintaxis no existe y se presta bastante a la metaprogramación (hacer programas que manipulan código, a que suena bien?), clojure, que es una versión más adecuada al siglo XXI de Lisp, más funcional si cabe y con el soporte de la máquina virtual java.

Finalmente ujfalusi, un lenguaje de programación ofuscado creado por el ponente, que nos dio la idea de crear nuestro propio lenguaje de programación, y tener la idea de cómo funcionan por dentro, y hacer algo realmente “geek” (No, ¡con esto no se liga!).

Paolo Perrota desde una perspectiva de Java o C#

La última sesión de la tarde, preparada, estuvo a cargo de Paolo Perrota, nos acercó a Rails desde la perspectiva de un programador Java o C# (estos bichos raros que ~~venimos~~ vienen de un mundo estático), comentó las principales diferencias, en las herramientas, en el diseño, en el uso de la línea de comandos como herramienta de programación VS uso de un IDE “grande y poderodo” como Eclipse, Netbeans o Visual Studio.

Fue una charla intensa y muy interesante que nos enseñó a ver con otros ojos otros lenguajes, a sentirnos incómodos con lo que hacemos y tengamos la necesidad de buscar algo más, y de tener un pensamiento más generalista a la hora de aprender un lenguaje nuevo, y que lo menos importante es la sintaxis.

Mini-sesiones como colofón final

Como colofón, tuvimos la oportunidad de ver mini-sesiones que surgieron a lo largo de la mañana donde vimos cosas como:

Crear una historia, contarla y vivirla, por Luismi Cavallé (pronunciado KAH-BAH-YEAH!) altamente recomandado si veis algo suyo.
Trucos para la shell de OSX, atajos de teclado que nos hacen la vida más fácil, por Jorge Dias
ElasticSearch, un motor de búsqueda interesante que podemos incorporar a nuestros proyectos, por Eli Kroumova
Sergio Arbeo nos presentó su “Alternative Programming Languages Interest Group“
Nacho Coloma habló de hashBang y pushState dos características que pueden dar bastante de que hablar (para recargar la web y cambiar de url sin hacer un refresco completo de la página)
Josh Kalderimis nos invitó a unirnos a su grupo Social Charity Collective, y donar el resultado de un fin de semana de trabajo a obras de caridad, hay mucha gente que puede estar necesitando nuestro código.
Fernando Martinez, también hizo de las suyas invitandonos a trabajar con él en su empresa , así que ya sabeis, si buscais trabajo Rails en Madrid, puede ser una oportunidad.

Mañana terminará el evento, y tendréis otro resumen como este,

¡Nos vemos entonces!

En la Conferencia Rails 2011: los talleres

En la Conferencia Rails 2011: los talleres

Roberto Luis Bisbé — Thu, 14 Jul 2011 10:45:02 +0000

El primer día: talleres

Hoy hemos podido difrutar de tres workshops que se presentan como introducción a la Conferencia Rails 2011, un evento que reúne profesionales del universo RoR para comentarnos sus experiencias, revelarnos trucos, pasar un buen rato y compartir.

Rompiendo el hielo con Ruby on Rails

La primera sesión estuvo a cargo de Raimond García, quien nos ayudó a romper el hielo con Rails, con un hola mundo desde 0, pasando por una introducción al modelo mvc, y a las particularidades de Rails, hasta el despliegue completo usando los servicios en la nube de Heroku. Una charla amena y entretenida, que nos permitió una vez terminada, probar por nosotros mismos cosas como enviar un e-mail a un usuario cuando se registre.

Programación funciona sobre Ruby

La segunda sesión fue un poco más fuerte, ya que estaba enfocada a las ventajas de usar programación funcional sobre Ruby. Arnau Sanchez nos mostró, entre otras cosas cómo implementar una versión muy básica de quicksort (uno de los algoritmos de ordenación por excelencia) en apenas 4 líneas, además enseñaba trucos para lograr un procesamiento paralelo de las operaciones. En mi opinión fue tremendamente interesante a pesar de mi falta de experiencia en Ruby. Como deberes me apunté aprender Haskell y F# (para un posible futuro artículo, tal vez).

Backbone.js

Tras la comida, una sesión de Backbone.js, un framework MVC basado en javascript, en el que estuvimos construyendo, bajo la tutela de Javier Arce una pequeña aplicación para calificar películas, tras una introducción a javascript desde el punto de vista del programador Ruby, impartida por Simon Tokumine, quien después estuvo explicando las particularidades de node.js, un framework que permite programación basada en eventos, y pudimos ver algunos ejemplos de uso (un servidor web, o un servidor de chat entre otros).

Mañana más y mejor

Felicitar a la organización de la conferencia, así como a los chicos de Madrid On Rails, por proporcionar las instalaciones para estas sesiones, y a los ponentes por su altísimo nivel técnico y la calidad de las ponencias.

¡Mañana más, desde Florida Park (El Retiro)!

En la Conferencia Rails 2011: las conferencias 1/2

Monográfico MVC: Introducción

Roberto Luis Bisbé — Mon, 27 Jun 2011 16:51:50 +0000

¿Por qué esta serie?

La semana pasada me surgió la necesidad de hacer un sistema de gestión de eventos para el DotNetClub del que formo parte y, aprovechando que lo estábamos estudando en la carrera, decidí emplear el patrón Modelo-Vista-Controlador (MVC).

El problema era que no me decidía si desarrollarlo en ASP.net o en Ruby on Rails, así que se me ha ocurrido hacer una pequeña implementación de la misma interfaz en los dos modelos para ver las diferencias, y ya que estaba, compartirlo con vosotros.

Como en un solo artículo es imposible dar siquiera una primera aproximación a cada una de las herramientas, lo hemos dividido en una serie, titulada Monográfico MVC.

A lo largo de esta serie, veremos cómo partiendo de un diseño básico, podemos agregar la lógica MVC, y apreciar las diferencias entre dos tecnologías concretas, y muy diferentes:

Ruby on Rails
ASP.net MVC3

Comencemos pues la introducción al patrón MVC.

Introducción: ¿Qué es MVC?

De acuerdo con la definición de Wikipedia es:

Patrón de arquitectura de software que separa los datos de una aplicación, la interfaz de usuario, y la lógica de control en tres componentes distintos.

Esto significa que tendremos tres componentes principales en nuestra aplicación:

Modelo

El modelo lo podemos ver como la base de datos, o el sistema relacional que controla cómo se leen y se guardan los datos, así como cierta lógica de validación y relaciones entre ellos (Lo podemos llamar modelo relacional, si estamos trabajando con bases de datos)

Vista

La vista es lo que se muestra al usuario o a un servicio web, es decir, una vista puede ser una página HTML para que el usuario acceda a los datos, una interfaz en Silverlight, o incluso un fichero XML que se consuma desde un programa externo.

Controlador

El controlador es el enlace entre la vista y el modelo, se encarga de recibir los eventos desde la vista (por ejemplo un botón “Enviar” de un formulario o de un cuadro de login) y de exponer a la vista los datos desde el modelo.

Este modelo no es nuevo, sino que fue introducido en 1987 en el lenguaje de programación SmallTalk, si quereis echar un vistazo a la especificación original, la podeis encontrar aquí: http://st-www.cs.illinois.edu/users/smarch/st-docs/mvc.html

Con el auge de las aplicaciones web, se ha demostrado ser un modo de programación que encaja bastante bien con internet, siendo tanto el modelo y el controlador ejecutados del lado del servidor, y la vista ejecutada del lado del cliente.

Diseño inicial

Para poder centrarnos en los diferentes sistemas y no centrarnos tanto en el diseño, partimos de un diseño HTML ya construido que contiene dos páginas:

Lista de eventos
Ventana de detalles

La lista de eventos contendrá la fecha, el título del evento, el ponente y una descripción.

La ventana de detalles contendrá, además, el edificio, el aula, y la hora, así como dos opciones para editar y/o borrar el evento.

Visto este diseño podemos extraer el conjunto de datos necesario, y su tipo:

Id: Integer
Titulo: String
Fecha: Date
Edificio: String
Ponente: String
Descripcion: String

A partir de este diseño, y usando técnicas de scaffolding, comprobaremos lo sencillo que puede ser empezar a trabajar.

En la próxima entrega veremos cómo agregamos lógica a esta web usando el primero de los jugadores: Ruby on Rails.

¡Nos vemos en la próxima publicación!

Cuestamenos, ahorra y gana dinero con tus compras y amigos

Adrián Mato — Wed, 18 May 2011 09:19:11 +0000

¿Ya estáis vendiendo patrocinados y spameando?

No, al igual que he publicado un artículo sobre Glibox hace ya algunas semanas mi idea con este tipo de publicaciones es echar un cable a todos los proyectos nacionales que quieran promocionarse. En realidad no publicamos cualquier cosa que nos manden, pero sí que lo hacemos con aquellos proyectos que realmente tienen un trabajo y una planificación detrás.

En esta ocasión el proyecto es Cuestamenos de Enrique Medina que ya ha colaborado anteriormente con Ontuts con alguna publicación sobre Grails.

¿Qué es Cuestamenos y qué ofrece?

El proyecto se resume en ahorra y gana dinero comprando e invitando a tus amigos. Ya ha sido presentado hace un tiempo en Loogic y me comentan que les ha sorprendido para bien la aceptación y acogimiento que ha recibido entre los usuarios que realizan sus compras a través de Internet.

Sin embargo, y gracias al feedback de la comunidad de usuarios, no han tardado en vislumbrar la necesidad de dotar de mayor usabilidad y visibilidad a la oferta de tiendas, productos y promociones, por lo que hace unas semanas han decidido ponerse manos a la obra y “reinventar” la web focalizando todos sus esfuerzos en una mayor facilidad a la hora de encontrar la información que buscamos.

El resultado según me comentan “ha sido espectacular a juzgar por las opiniones y comentarios de nuestros usuarios y el creciente volumen de nuevos registros”.

¿Cuáles son las novedades que nos encontramos?

Son muchas y variadas por lo que os las listo en secciones para que os sea más cómodo de entender:

Usuarios: ¿Por qué no premiar a los usuarios más activos? El programa de referidos permite a los “padrinos” beneficiarse también de las compras y registros de sus referidos. Por ejemplo, si tú como usuario recomiendas a varios conocidos que terminan dándose de alta en cuestamenos.com, por cada compra o registro que estos referidos tuyos hagan, tú te llevas un porcentaje adicional de esa ganancia.
Home: Una “fotografía” inmediata y clara de “qué está pasando”, así no se le escapara ni una sola oportunidad de ahorrar y ganar dinero al usuario. Para ello han rediseñado la home para que se asemeje a un “dashboard” o cuadro de mandos desde donde poder ver las últimas ofertas y tiendas. Además, han rediseñado los menús para hacerlos más intuitivos y manejables.
Ganancias: Hasta ahora podíamos comprobar nuestras ganancias dentro de nuestra cuenta, pero era bastante difícil tener una visión global de si realmente estábamos ahorrándonos dinero o no. Han añadido gráficos y una tabla mucho más dinámica para el detalle de las ganancias que permite ordenar, filtrar, etc.
Comunicación: Conscientes de que no todos los usuarios pueden entrar a la web en cualquier momento, han mejorado el detalle de información que se manda en nuestras comunicaciones por correo, de forma que ahora. Más detalle, más información, más transparencia, mejor control.
Productos: Aunque la anterior versión de la web ya proporcionaba una búsqueda básica de productos, la calidad de los resultados era bastante mejorable. Así, han incorporado una nueva búsqueda más rápida, certera y, sobre todo, que te permite navegar por los resultados, filtrarlos, ordenarlos, para que ningún producto se te escape y puedas encontrar sólo lo que buscas.
Promociones: De la misma forma que ahora se pueden buscar productos con un buen nivel de detalle, también han querido añadir esta funcionalidad a las promociones, de forma que puedas encontrar el cupón, descuento o ganga que estés buscando sin esfuerzo.

Todo esto está muy bien pero… ¿por qué Cuestamenos y no otros?

Ha sido una de las preguntas que se me han venido a la cabeza, y su respuesta en resumen es que hay otras web que aparentemente ofrecen el mismo tipo de servicio, pero aún así creen firmemente que cuestamenos.com está varios pasos por delante de ellas, no sólo por madurez y facilidad de uso, sino porque:

Ofrece el mayor porcentaje de ganancias, y si eres VIP, el 100%.
Búsqueda avanzada por precios, categorías y tiendas con más de 6 millones de productos. Cuestamenos ofrece un programa de referidos con el que ganas directamente si ellos compran o se registran en las tiendas.
Sistema avanzado de control de ganancias mediantes gráficas y otras herramientas. Además ofrece la posibilidad de cobrar tus ganancias bien por Paypal bien por transferencia directa en cuenta dentro de España, y sin absolutamente ningún tipo de comisión para ti.
Sólo Cuestamenos ofrece un servicio de atención gratuito al usuario que responde en pocas horas, incluso en minutos.

Pero aquí no acaba todo…

Porque para celebrar la nueva web regalan a todos los nuevos usuarios 1€ sólo por registrarse, sin tener que hacer ninguna compra, sólo porque estamos convencidos de que una vez que nos pruebes, ya no sabrás comprar online si no es a través de cuestamenos.com.

Por mi parte sólo me queda felicitar a Enrique y todo el equipo y desearos mucha suerte, ¡dadle caña al proyecto!

¡Probadlo y no dudéis en enviarles feedback via comentarios!

No related posts.

Marcas de agua en imágenes usando PHP (I)

Gonzalo Ayuso — Tue, 10 May 2011 16:26:02 +0000

Imaginando una biblioteca de imágenes… ¡Demasiado trabajo!

Imaginemos que tenemos un biblioteca de imágenes y que queremos añadirles una marca de agua a todas ellas. Podemos abrir un editor de imágenes (Gimp o Photoshop, por ejemplo) y crear nuestra marca de agua manualmente a todas ellas.

Es un trabajo sencillo pero si nuestra biblioteca de imágenes es muy grande el trabajo se convierte en algo más duro. Podemos automatizar esta tarea, pero si las marcas de agua que queremos poner son dinámicas, tenemos que buscar otra solución. Como ejemplo imaginemos que lo que queremos poner es la fecha/hora en la que el usuario solicita la imagen al servidor. Para hacer esto vamos a usar la librería GD y PHP. Empecemos:

Gracias a la librería GD podemos añadir de manera sencilla marcas de agua a nuestras imágenes. Esto Unido a mod_rewrite nos permite hacer el trabajo al vuelo.

¡Automaticemos el trabajo!

La idea es simple. En lugar de abrir directamente la imagen, lo que vamos a hacer es crear un script PHP que modifique la imagen original con la función imagecreatefromjpeg y le añada un footer con la fecha/hora . Después le entregaremos al navegador la imagen modificada con las cabeceras necesarias.

Esta solución nos implica modificar todas nuestras etiquetas img y pasar de algo así:

A algo así:

Para evitar esto vamos a usar un pequeño truco que consiste en usar el módulo mod_rewrite de apache (los demás servidores Web tienen módulos similares). Creando este simple archivo .htaccess en la carpeta donde tengamos nuestras imágenes jpg, podemos redirigir cada petición de la imagen original a nuestro script PHP que la modifica y le añade la marca de agua.

RewriteEngine on
RewriteRule !\.(php)$ watermark.php

Ahora creamos nuestro script watermark.php para hacer la modificación.

Como vemos el script es muy sencillo. Podemos modificarlo y cambiarlo por nuestro logotipo, o introducir nuevos valores. Para que esto funcione tenemos que tener nuestra instalación de PHP compilada con soporte GD.

Imagen Original:

Imagen transformada:

Una pequeña reflexión final

Y eso es todo. ¿Qué pega tiene esta técnica? Pues que estamos usando unos recursos del servidor elevados. Estamos transformando la imagen cada vez que la solicitamos. Si el volumen de peticiones es pequeño no hay problema, pero si crece podemos tirar el servidor.

Una solución sencilla es cachear la imagen resultante. De este modo liberamos al servidor, pero ¿que pasa si la marca de agua es dinámica?. En el siguiente artículo de esta mini serie veremos una posible solución al problema.

¡Nos vemos en el próximo capítulo!

vanilla: theme corporativo y portfolio para WordPress

Adrián Mato — Fri, 22 Apr 2011 12:07:43 +0000

¿Qué es vanilla?

vanilla es un theme corporativo y portfolio para aquellos que trabajan con el gestor de contenidos WordPress. Anteriormente WordPress era meramente utilizado para blogs pero es un hecho que el paso del tiempo y su popular aceptación lo hayan reconvertido en el CMS referencia para mucho tipo de proyectos.

No creo que WordPress valga para todo pero realmente para proyectos pequeños y medianos aporta mucha versatilidad y sobretodo rapidez.

El theme ha sido creado por un servidor y viene acompañado de un sistema de rotación de imágenes en la portada permitiendo mostrar nuestros últimos trabajos con un montón de efectos diferentes para captar la atención del visitante.

No importa si tus conocimientos de WordPress son escasos o amplios, el theme cubre ambos perfiles. ¿Cómo? Pues porque viene acompañado de un panel de administración de forma que rellenando formularios puedes personalizar y configurarlo a tu gusto.

De esta forma podrás por ejemplo añadir diapositivas al sistema de rotación de imágenes de portada, añadir proyectos a la galería, entradas en el blog, configurar tu cuenta de twitter, galería de flickr, dos sidebars completamente configurables mediante widgets y todo esto y mucho más sin tocar una línea de código.

Además viene acompañado de 8 archivos PSD por lo que podrás personalizar colores y el “look & feel” general si algo no te convence de forma fácil y cómoda.

Algunas características destacadas de vanilla

Como os comentaba al inicio el theme viene cargado de opciones y características algunas de las más destacadas son las siguientes que os listo a continuación:

Rotación de diapositivas en portada completamente configurable.
Galería de proyectos: imágenes y vídeos soportados.
Página de contacto PHP lista para utilizar sin código.
Un montón de shortcodes personalizados.
Menú desplegable completamente personalizable.
Habilitado para el uso de widgets.
Template de páginas de ancho completo sin columnas adicionales.
Página de error 404 personalizada.
Posibilidad de añadir imágenes destacadas a las entradas del blog.
Comentarios anidados.
Último mensaje publicado en Twitter.
Galería de imágenes flickr como widget.
Compatible con la mayoría de navegadores actuales (incluyendo IE7 y IE8).

Seguramente se me escapen algunas pero espero haberme acordado de las más importantes.

¿Cómo puedo conseguir el theme?

En esta ocasión el theme no viene en forma de recurso gratuíto como acostumbramos a publicar. La forma en la que lo hemos publicado ha sido mediante el marketplace de los chicos de Envato llamado como Themeforest.

El precio del theme es de 35$ pudiendo ser comprado aquí mismo. Además del propio theme hemos incluído una completa documentación para seguir paso a paso a la hora de configurar todas las distintas opciones en caso de que no encontréis lo que buscáis.

¿Por qué no hemos publicado el theme de forma gratuíta? Sinceramente porque ha costado muchas horas de diseño, maquetación y programación y el resultado final me ha hecho convencerme que debía cobrar por ello .

Espero que os haya gustado y si tenéis alguna crítica o sugerencia para mejorar este o próximos diseños… ¡no dudéis en compartirla por favor!

Las tres opciones del emprendedor: El bueno, el feo y el malo

Javier López — Fri, 08 Apr 2011 09:07:36 +0000

A la hora de emprender, y si simplificamos el asunto, cualquier emprendedor que comienza a dar sus primeros pasos tiene tres opciones: El bueno, el feo y el malo.

El Bueno

“El Bueno”, y lo llamo así porque para mí es lo ideal para alguien que salta a la piscina por primera vez, consiste en hacer algo hoy y ponerlo a la venta ayer. Haz algo, ponle un precio y véndelo cuanto antes.

Tan pronto como lo hayas movido un poco y estés ganando tus primeros euros, vuelve al primer paso y crea otro producto. O bien itera sobre él para que genere aún más dinero.

Así de simple. Crea un producto completo, en el mínimo tiempo posible, y véndelo en internet. Te vale casi cualquiera cosa. Por ejemplo:

Mini-videojuegos: para Flash, Iphone, Adroid, PC, etc.
Aplicaciones para móviles
Themes para webs y WordPress
Ebooks
Fotografías
Iconos
Loops de música o sonidos FX
Servicios web con diferentes planes y precios. Rey de los ejemplos: BaseCamp
Etc…

Hay tantas opciones como imaginación tengas.

Código fuente filtrado de origen desconocido con el algoritmo en cuestión. ¡Úsalo bajo tu propio riesgo!

10 Haz un producto
20 Ponlo en venta
30 Múevelo
40 GOTO 10

¿Te suena la palabra “passive incoming“? Lleva de moda varios años. Cualquiera de los productos que te he comentado puede convertirse en un passive incoming. Simplemente es un producto que pones a la venta, y mientras trabajas en el siguiente, el anterior está generando beneficio.

Si insistes en esa mecánica (crear producto nuevo mientras vendes el anterior) la bola de nieve irá creciendo, y aunque productos antiguos vayan decayendo con el tiempo, si haces una gráfica en modo campana, verás que con constancia irás teniendo unos ingresos remanentes incrementales que pueden hacer que vivas muy, pero que muy, bien.

¿Acaso no hiciste negocios en el cole vendiendo fotocopias de las Tortugas Ninja? (Verídico en mi caso, sólo que yo encima puse a mi hermana a dibujar láminas de monstruos que luego fotocopiaba y vendía). Pues “El Bueno” es casi lo mismo.

Algunos detalles a tener en cuenta:

El producto que hagas, tiene que ser un producto acabado, o al menos una beta que merezca la pena pagar por usar.
Es mejor sacar algo en 3 meses que no esté del todo perfecto y luego iterar sobre él. Que tardar 6 meses y sacarlo perfecto. “Perfecto” es muy relativo. Será perfecto para ti… pero sería mucho mejor haberlo sacado 3 meses antes y estar 3 meses iterando sobre él, recibiendo feedback constante de los usuarios, siendo ellos los que marquen el rumbo de la nueva release.
Ponte un tiempo de desarrollo muy estricto y que sea el menor tiempo posible.
Si el tiempo de desarrollo que calculas es mayor de 6 meses, piénsatelo mucho. Lo ideal sería algo que pudieras tener terminado en 3 meses. Al menos si es la primera vez que vas a vender algo.
Si lo empiezas, acabalo. “Hazlo, o no lo hagas, pero no lo intentes“.

Con “El Bueno” puede que no te hagas multimillonario, pero si que puede darte para un sueldo muy decente. Además, estarás continuamente haciendo proyectos nuevos y sacando nuevas ideas. Esta opción es muy entretenida.

¡Qué haces leyendo esto aún! ¡Ve y hazlo!

El Feo

Otra opción, “El Feo“, muy socorrida cuando a una startup está intentado que “El Malo” funcione y le falta liquidez (o al menos ese es nuestro caso), es hacer trabajos para terceros. Es decir, diseño y desarrollo web, aplicaciones para móviles, etc… todas esas cosas que por suerte o por desgracia ofrecemos en Cokidoo.

Vale, da de comer, pero se parece demasiado a trabajar en una empresa con un sueldo… o como diría mi socio Iván… ¡es peor! Al menos si trabajas en una empresa como diseñador gráfico asalariado no tienes que preocuparte de si la empresa va bien o mal, o de si entran más o menos clientes… ¡ya está el jefe para eso!

Pero si empiezas a hacer trabajos para terceros, de pronto tu universo de preocupaciones se llenará de:

Encontrar nuevos clientes
Trabajar en las ideas de otros… ¡eso no mola!
Entregar todos los curros a tiempo, echando tantas horas extra como hagan falta.
Que los clientes que tardan en pagar, paguen.
Tener poco tiempo para “El Bueno” o “El Malo”.

Partiendo de la base de que no quieres trabajar en una empresa con un sueldo, sino que quieres ser tu propio jefe y desarrollar tus propias ideas, esta opción, puede que te permita aguantar durante una temporada en la que “El Bueno” o “El Malo” no te dan de comer, pero a la larga, no hará más que quemarte.

Vale, hay excepciones. Hay freelancers que viven contentos haciendo esto y les va muy bien… pero más contentos estarían seguro si hubieran conseguido lo que Envato, que partiendo de un blog para freelancers han acabado creando marketplaces, redes de blogs de tutoriales y literalmente forrándose.

Dribbble debe estar cargadito de freelancers muy felices haciendo sus cosas, pero cuando un cliente les aprieta, fijo que muchos de ellos preferirían echar horas extra trabajando en un proyecto propio que invertirlas en un cliente.

El Malo

“El Malo” es ese proyecto que los inversores están cansados de ver, pero que por otra parte es el único en el que merece la pena invertir, porque a largo plazo podría ser un pelotazo.

Es un proyecto que va a necesitar mucho de tu tiempo y mínimo dos o tres años para empezar a ser rentable, si es que alguna vez lo es. Tiempo durante el cuál tus opciones se reducen a buscar financiación, con lo que tendrás uno o dos años para tu equipo aseguradas si la primera ronda de inversión es mínimamente decente… o bien apretarte el cinturón y salir de copas con “El Feo”. Es decir, trabajar en tu proyecto a la vez que para terceros… cuando los clientes aprietan por las entregas y a la misma vez intentas sacar adelante tu propio proyecto, te aseguro por experiencia, se hace duro.

Lo llamo “El Malo” porque muy pocos triunfan con este modelo. Muy pocas redes sociales o comunidades llegan a ser rentables, por no decir casi ninguna.

No obstante, si tienes muy claro lo que vas a vender, y no está basado en la mera publicidad (generar tráfico y esperar ganar dinero con publicidad o afiliados es muy complicado), puede que te salga bien. A empresas como Atrapalo, Privalia o Buyvip no las habría categorizado antes de empezar como “El Malo”. Esas empresas desde el día uno tenían algo para vender, y luego ya tenían que preocuparse de generar visitas y comunidad para vender aún más. Es muy distinto de por ejemplo hacer una web o comunidad de contenido útil como Erasmusu.com y luego intentar sacar dinero con publicidad o afiliados. Erasmusu es la leche en cuanto a comunidad, visitas y páginas vistas se refiere… pero no ha sido nada fácil empezar a que sea rentable.

Y si buscas inversión porque no quieres perder el tiempo trabajando para terceros y quieres enfocarte totalmente en tu proyecto, olvídate de que inviertan en una idea… como mínimo deberás tener un prototipo… y un buen “exit plan”, cuya traducción a la lengua de Cervantes o lo que el inversor ve en su cabeza es: “¿cómo pijos voy yo a sacar pasta de este asunto?”. Recuerda, al inversor le podrá motivar más o menos tu proyecto, pero lo que el quiere, es ganar dinero. Ni más, ni menos. Así que si no ve claramente lo que vas a vender, a quién se lo vas a vender y cómo lo vas a vender… ¡olvídate! Aparte, conozco gente que ha estado año y medio únicamente buscando financiación… ¡no es fácil!

Con “El Malo” me refiero pues a aquellos proyectos que de por sí, no venden nada concreto, y que necesitan una gran cantidad de visitas para desarrollar modelos de negocio en torno a ellos y empezar a ser rentables. Me refiero a las redes sociales, comunidades online, foros, etc.

¡Ojo! Cualquier marketplace de Envato tiene una comunidad y foros detrás. Pero no me refiero a este tipo de comunidad. Esa comunidad está ahí para comprar o crear nuevos productos y empezaron primero como marketplace, luego como comunidad.

En contraposición al “El Malo” está “El Bueno”. Si haces un theme para ThemeForest hoy y lo consigues poner en venta… durante la siguiente semana ya estarás teniendo tus primeros ingresos y la bola de nieve comenzará a rodar.

“El Bueno” podría convertirse también en un pelotazo digno de que algún inversor hubiera puesto pasta… por ejemplo este videojuego de Iphone hecho por una sola persona debe haber generado muchísimo dinero. Pero lo normal es que los productos que crees, si eliges la opción del “El Bueno” te den un muy buen sueldo, pero no atraigan a ningún inversor… ¿y quién los necesita?

Claro esta, si te sale bien, “El Malo” es el que podría hacerte rico, muy rico. Como le has pasado a Twitter, Facebook, etc. ¡No quiero ser yo el que te desilusione!

Pero aún así, aún existiendo esa posibilidad, es mejor que empieces por “El Bueno”, durante como mínimo dos años, porque aprenderás mucho en el camino y podrás utilizarlo más adelante para arriesgarte en “tu gran proyecto”.

See you in another life!

No related posts.

¡Concursa y Gana una Camiseta del equipo Cokidoo!

Adrián Mato — Fri, 25 Mar 2011 12:44:11 +0000

Actualización: ¡Ya tenemos a los 3 ganadores!

Nos gustaría dar las gracias a todos los participantes, han sido muchos más de los esperado y la verdad estamos muy contentos de la respuesta de todos en los distintos canales: facebook, twitter o el propio blog.

Y ahora vamos con lo que os interesa, estos han sido los 3 ganadores:

Enhorabuena alos tres, en breves nos pondremos en contacto con vosotros para pedir vuestra talla de camiseta y la dirección de envío.

¡Gracias a todos por participar y suerte para el próximo!

Sorteamos 3 camisetas de Cokidoo

De la mano de los chicos de LolaCamisetas esta vez sorteamos tres fantásticas, impresionantes, galácticas y exclusivas camisetas de Cokidoo.

Los ganadores serán anunciados el 4 de Abril y recibirán una de las camisetas con la talla que deseen en su domicilio, lógicamente sin gastos de ningún tipo .

¿Cómo puedo participar?

Para participar tan sólo tienes que comentar en twitter por qué te gustaría ganar la camiseta mencionando al usuario @ontuts o bien en nuestro Facebook dejando también un pequeño mensaje con el que convencernos de que debas ser el elegido.

Ejemplo: Debo ganar una de las camisetas que sortea @ontuts porque nadie les ha hecho tanto la pelota como yo!

¡Mucha suerte a todos!

Acerca de LolaCamisetas

Para los que no los conozcáis os recomendamos que visitéis su web en la que podréis encontrar todo tipo de camisetas originales y divertidas, llegando incluso a poder personalizar vuestras propias camisetas.

Desde Ontuts queremos dar las gracias a LolaCamisetas por el interés en participar en el concurso con nosotros, ¡da gusto tratar con gente así de agradable!

Creando servicios de red TCP con PHP y xinetd

Gonzalo Ayuso — Thu, 17 Mar 2011 13:15:21 +0000

Introducción

No todo en PHP es Web y HTTP. Podemos usar PHP para muchas otras cosas. Por ejemplo podemos crear de una forma muy sencilla servicios de red. Cuando creamos servicios de red necesitamos obviamente un servidor de red (bien sea TCP o UDP).

Cuando trabajamos con Web y HTTP este servidor suele ser Apache (o similares), pero si queremos crear un servicio específico (no HTTP), además del servicio de red que queramos crear, necesitaríamos crear un servidor.

No todo en PHP es Web y HTTP. Podemos usar PHP para muchas otras cosas. Por ejemplo podemos crear de una forma muy sencilla servicios de red.

Esto lo podemos hacer con C, Java e incluso con PHP, pero cuando trabajamos en entornos Linux existe un daemon que nos permite desplegar servicios de red de una forma muy sencilla, encargándose de la parte del servidor y dejándonos a nosotros la parte del servicio de red. Este daemon es xinetd.

Vamos a ver cómo crear un sencillo servicio de red TCP con xinetd y PHP… ¡Empecemos!

Creando el servicio de red TCP con Xinetd y PHP

El ejemplo que vamos a realizar escuchará del puerto 69321, e inicialmente dirá “Hola” cuando alguien realice una petición TCP a dicho puerto. El script del ejemplo es sumamente complicado:

// /home/gonzalo/tests/test1.php
echo "HELLO\n";

Bien. Ahora lo que queremos es que nuestro servicio de red escuche el puerto tcp 60321. Para esto tenemos que definir en nuestro archivo /etc/services el puerto en cuestión:

// /etc/services
...
myService   60321/tcp # my hello service

Y finalmente creamos la configuración en el daemon xinetd. Para ello creamos el archivo /etc/xinetd.d/myService:

# default: on
# description: my test service

service myService
{
        socket_type = stream
        protocol = tcp
        wait = no
        user = gonzalo
        server = /usr/local/bin/php-cli
        server_args = /home/gonzalo/tests/test1.php
        log_on_success += DURATION
        nice = 10
        disable = no
}

Reiniciamos el daemon para que lea la nueva configuración del servicio que hemos creado:

sudo /etc/init.d/xinetd restart

Y listo. Ya tenemos nuestro servicio de red operativo y funcionando. Para probarlo podemos usar un simple telnet al puerto definido:

telnet localhost 60321
Trying ::1...
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Hola
Connection closed by foreign host.

¿Fácil, no? Sí pero útil, no mucho. Por esto vamos a cambiar un poco es script para que acepte variables de entrada. Esto no es HTTP por lo que no podemos usar las típicas variables $_POST y $_GET.

Lo que tenemos que hacer es leer del stdin. En PHP, al igual que con otros lenguajes, esto es muy sencillo:

$handle = fopen('php://stdin','r');
$input = fgets($handle);
fclose($handle);

echo "Hola {$input}";

Reiniciamos el xinetd y tenemos nuestro servicio listo

telnet localhost 60321
Trying ::1...
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.

Vemos que el telnet se nos quedará a la espera que introduzcamos un texto. Escribimos: “gonzalo” y obtenemos:

gonzalo
Hola gonzalo
Connection closed by foreign host.

Conclusión

Y esto es todo. Con este sencillo script vemos que, si bien PHP es un lenguaje destinado principalmente para el desarrollo Web, podemos usarlo para otras cosas, manteniendo su punto fuerte: la sencillez.

¿Para qué nos puede servir esto? Bueno. Para empezar nos sirve para leer datos de dispositivos de red que tengamos por ahi, como báculas, lectores de tarjetas, sensores… Muchos de estos dispositivos suelen permitirnos en su configuración establecer una IP/puerto a la que van a enviar información en forma de trama TCP.

También podemos usarlo para comunicar procesos de una manera simple, sin necesidad de meternos con servidores XMLRPC/Soap y demás. En fin que es una herramienta más que tenemos a nuestra disposición para afrontar nuestros desarrollos.

¡Nos vemos en el próximo artículo!