Posts con la categoría ‘Tutoriales’

Modelos de negocio al hacer una página web

Escrito en Tutoriales

Como programadores web, dueños de varias páginas web como sortea2, opinionescompra o contarproteinas. nos hacen la eterna pregunta:

¿Pero cómo se gana dinero haciendo páginas web? ¿Quién te paga?

He contestado a esta pregunta decenas de veces, unas con más ganas y otras con menos (dependiendo de cómo me cayera el interlocutor o mi estado de ánimo). Dado que ahora mismo sí estoy de buen humor, listaré algunas de las maneras en que es posible ganar dinero mediante Internet.

Nada de ver vídeos de anuncios como un zombi para ganar 2 euros. Nada de prostituir tu agenda de contactos para freírles a spam.

Publicidad

Este mismo blog tiene publicidad. Hay dos tipos de publicidad:

  • Por número de visitas: Te pago 2€ por cada mil veces que se vea el anuncio. Este modelo es súper ineficiente. Quizás de esos mil usuarios nadie hizo clic o prestó la mínima atención al asunto. Solo es válido para páginas con una cantidad enorme de visitas (más de 100.000 al mes). Es casi imposible acceder a anunciantes a no ser que hagamos labores de comercial o que la vendamos a precio de saldo. Esta opción está casi descartada.
  • Por número de clicks. Te pago 15 céntimos de euro por cada clic válido que vaya a mi página web. Este modelo sí es eficiente porque al fin y al cabo, el usuario tiene un interés en ver de qué se trata el anuncio. Pocas, pero hay algo de opciones de que se acabe sacando la tarjeta de crédito del bolsillo para comprar algo. Este modelo es modular, cuantas más visitas, más clics se producirán.

¡Excelente! Voy a hacer una web, con publicidad a saco y ganaré pasta.

No tan rápido. Primero hay que averiguar cómo conseguir los anunciantes. Hay tres maneras:

  1. Encontrar los anunciantes a mano. A menos que seamos un medio prestigioso, nadie va a querer anunciarse en nuestra página. Y si lo hace, será a precios ridículos. Esta opción está casi descartada si estamos empezando.
  2. Google Adsense. El 28% de los ingresos de Google provienen de esto (9.71 billones de dólares según la wikipedia). Tú pones en tu web un código que Google te da y él se encarga de gestionar los anunciantes  y toda la parte compleja. A cambio, tú te llevas el 68% de los beneficios y Google el resto (que en total son 9.78 billones, o sea, que no es poco).
  3. Alternativas a Adsense. Hay alternativas, pero todas, sin excepción son peores. Y si nuestra página está en español, ya mejor ir olvidándose del tema.

Como vemos, Google Adsense es la opción más recomendable. A nosotros nos paga el 68% de los ingresos, pero aún así es más que lo que conseguiríamos por nuestra cuenta o usando otra red publicitaria seguramente. Además, este porcentaje es transparente. Nunca tenemos por qué saber esto. Simplemente preocuparnos de cuánto cobramos nosotros.

¿Cómo funciona Google Adsense?

Tú pones el código que Google te da en tu web. Por cada usuario que cargue tu página, Google analizará la página en la que se encuentra, para ofrecer anuncios que estén relacionados contigo. Además, sabrá tu dirección IP, por lo que puede imaginarse en qué ciudad estás. Además, es posible que tengas una cuenta de gmail. En ese caso, el navegador tendrá una cookie con la sesión de ese usuario. No se dedicará a leer tus correos, pero sí podrá afinar más quién eres. También podrá cruzar esos datos con un posible perfil en Google+.

En definitiva, Google trata de ofrecer los anuncios más relevantes para el usuario que se encuentra visitando tu página. Si estás en una página de Tarot y te ofrezco apuestas combinadas en Bwin.es, seguramente pases completamente del tema. Si estás en un blog sobre la bolsa americana y te ofrezco un fondo de inversión indexado al S&P 500 sin comisiones de apertura, hay más probabilidades de que te interese.

Tras la valoración del sitio y del usuario que se encuentra viendo la publicidad; y si el usuario hace clic sobre ella, Google generará beneficios para tu página. El anunciante que contrata la publicidad con Google pagará por ese clic un precio variable, según las características del usuario y la calidad de la página. Si es un anuncio de un restaurante en Almería y el usuario visita la página desde Canadá pagará menos que si el usuario es de Almería.

El precio de un clic es totalmente variable. Si todo pinta como algo fraudulento, o tiene valor cero, el clic valdrá cero euros. Si el usuario es 100% lo que el anunciante anda buscando y es un anuncio de una temática muy competida, el clic valdrá mucho más. He llegado a ver clics de más de doce euros (un único clic). Eso sólo ocurre muy de vez en cuando, lo normal es que valga menos de un euro.

Cabe destacar que Adsense funciona mejor para usuarios de Estados Unidos, Canadá, UK, etc. En España casi todos los clics son de menos de un euro. En los otros países es más fácil encontrarse con clics de los grandes.

Lo normal es que menos de un diez por ciento de los usuarios haga clic en un anuncio. Más de eso sería una página completamente fraudulenta que sería baneada en cuestión de días seguramente. En una página en la que la publicidad esté escondida y apenas destaque, con un 2% nos podemos conformar.

Una cosa que no podemos hacer bajo ningún concepto es clicar sobre nuestros propios anuncios o pedirle a la gente que lo haga. Como hemos dicho, Google dispone de un montón de información sobre el usuario que ha hecho eso. Para empezar, si tú haces clic lo más normal es que estés logueado en tu cuenta de google (la cual usas para consultar el saldo de adsense), por lo que Google sabe a ciencia cierta que eres tú mismo. Si una misma persona hace clic todos los días en la misma página, también sabe que eso es fraudulento, porque guarda un histórico de todos los clics.

Google avisa una vez, pero a la segunda te cierra la cuenta de por vida y ya nunca te deja volver a abrirla (quizás en 50 años sí, pero no se ha dado el caso todavía).

Google paga por transferencia bancaria una vez al mes. Nunca paga menos de 75€. Si en un mes no se alcanza eso, se pagará el mes en que se acumule esa cantidad.

 Afiliados

La segunda gallina de los huevos de oro en Internet es el marketing de afiliados. Aquí, en vez de simples clics, lo que estamos buscando es que el usuario haga o compre algo de verdad. Ya de nada sirve que el usuario tenga algo de interés y haga clic. Aquí el usuario se tiene que sacar la tarjeta de crédito del bolsillo sí o sí para cobrar. Dado que aquí el anunciante no está arriesgando nada (si no paga el usuario, el dueño de la web no cobra nada), puede pagar mucho más, porque son ventas reales en su negocio. Lo normal es llevarse un porcentaje de la venta, con ciertos límites a veces (máximo de 10€ de comisión, por ejemplo).

Aquí poner la publicidad de fondo por si alguien le interesa ya no es suficiente. Ahora hay que hablar del producto, dar algo de valor añadido. Incentivar al usuario a comprar.

Una vez el usuario hace clic, el vendedor crea una cookie en el navegador del usuario. Lo que compre ese usuario en X horas tiene tu sello de afiliado y te llevarás una comisión por ello. Da igual que el usuario haya pinchado en el anuncio de un cepillo de pelo y acaba comprando Crepúsculo en DVD.

El porcentaje suele ser variable. No es lo mismo vender libros y DVDs (que tienen mucho margen de beneficio) que vender electrónica, que está mucho más competida.

Programas de afiliados hay cientos. Cada uno tiene unas condiciones. Su funcionamiento es siempre es el mismo: si el usuario hace X en mi página, tu página cobra un porcentaje.

El más conocido es el de Amazon. Pero si vamos a hacer una página web de una temática un poco común, seguramente haya algún programa de afiliados de esa temática (seguros de coche, venta de coches siniestrados, apuestas online, etc.).

Como el software que hace funcionar un sistema de afiliados es bastante complejo (es difícil controlar quién viene de dónde, cuánto se le tiene que pagar a cada uno, etc.), existen agregadores de afiliados, como Zanox, Affilinet, etc.

Normalmente los enlaces de afiliados contienen información sobre el dueño de la web que utiliza el servicio de afiliados. Así luego la tienda online puede saber de dónde viene.

Cada uno es de su padre y de su madre así que tenemos que leer las condiciones y entenderlas bien. En unos te pagarán cuando alcances 30€ de saldo. En otros no te pagarán comisiones de más de 10€. En otros no podrás nombrar la marca que estás anunciando, etc.

En el programa de afiliados de Amazon, lo máximo que pagan es 10€ por producto. Pagan mensualmente mediante transferencia o mediante cheque regalo de Amazon (opción abierta a todo tipo de chanchullos que retroalimenten al chiringuito). Las comisiones varían según la categoría del producto.

Si tenemos un blog que hable sobre lavadoras y frigoríficos, nos pueden interesar otros programas de afiliados en los que no esté el límite de 10€, porque podremos ganar mucho más dinero.

Si somos más listos de la cuenta, podemos decirle a nuestros amigos y familiares que utilicen nuestros enlaces de afiliados para comprar en esas páginas y llevarnos un porcentaje de comisión.

Vender cosas

Esta es la vertiente en la que menos conocimiento tengo. Es un terreno complicado porque requiere algo más de profesionalización. No podemos estar vendiendo motosierras por Internet sin garantía ninguna, sin saber qué hacer cuando nos devuelvan un pedido o sin siquiera estar dados de alta como empresa.

Sólo es recomendable si vamos a ser capaces de crecer y suplir la demanda que se nos pida. Requiere una gran dedicación y necesita de inversión monetaria inicial.

Nunca podemos caer en los siguientes problemas:

  • Que nos hagan 10 pedidos y que si uno de ellos falla ya estemos perdiendo dinero porque nos tengamos que comer con patatas ese producto.
  • Que nos hagan un pedido mínimamente grande y no seamos capaces de satisfacerlo.
  • Que nunca haya stock de los productos. Que tengas que comprar primero y enviar luego. Eso causa frustración al usuario y hace que todo vaya muy lento.
  • Que un cliente enfadado nos denuncie y no estemos ni dados de alta ni nada. En los anteriores modelos de negocio nadie debería quejarse de nosotros (en principio). Al tratar con los clientes de uno en uno, es más fácil que haya quejas.

En este tema no ahondaré mucho porque se me escapa de las manos. Sólo lo recomendaría si:

  • Vamos a vender algo que producimos nosotros o que conseguimos a muy bajo precio (sólo nosotros).
  • Vamos a emprender a gran escala y hacer algo medio en condiciones que de trabajo a largo plazo (dados de alta como empresa, con su pago de impuestos, etc.).

Vender servicios

Aquí en vez de vender cosas tangibles, vendemos servicios o nuestro tiempo por hacer algo. Así nos quitamos de un plumazo gran parte de los inconvenientes porque no tendremos que tratar ni con proveedores ni con empresas de transporte.

Además, si un cliente pide que se le devuelva el dinero, lo más normal es que nosotros sólo perdamos tiempo, no dinero. Al no vender cosas rotas ni tener que lidiar con garantías oficiales, lo normal es que si alguien está insatisfecho, con devolverle el dinero ya esté contento.

Aquí es conveniente estar dado de alta y demás porque algunos usuarios pedirán factura. Siendo honestos, esto ocurre muy raramente y lo mejor es empezar tanteando el mercado y darse de alta cuando eso empiece a dar beneficios (no digas que esto te lo hemos dicho nosotros).

Por ejemplo, en Sortea2 ofrecemos tres servicios:

  • Sorteos certificados: en vez de un sorteo normal, haces un sorteo certificado que garantiza que no se ha repetido el sorteo varias veces y hace comprobaciones de fiabilidad extra. El organizador obtiene mayor credibilidad simplemente pagando 2.99€.
  • Publicar promociones: alguien está organizando una promoción y obviamente, quiere que se apunte el mayor número de personas posible. Para ello, puede publicar un anuncio en nuestra web. Hay opciones de pago que ofrecen más posibilidades de personalización (más enlaces, más imágenes, el anuncio sale más destacado, etc.).
  • Organizar sorteos en redes sociales: alguien está pensando en hacer un sorteo para conseguir fans en Facebook o followers en Twitter y sabe que luego contabilizar quién ha participado es prácticamente imposible (en caso de Facebook, imposible si tiene más de 500 fans), por lo que paga 4.99€ para toda esa gestión la hagamos nosotros.

Nosotros, los dueños de Sortea2 no tenemos que hacer nada, porque son sistemas automáticos. Simplemente tenemos que estar atentos al correo electrónico por si algún usuario tuvo algún problema o para devolver algún pago erróneo (cosa que rara vez ocurre).

Al vender cosas o servicios, es importante escoger qué método de pago utilizamos, porque puede ser un factor decisivo. Normalmente la disyuntiva es la siguiente:

  • Pasarela de pago por tarjeta de crédito: tendremos que ponernos el traje y la corbata e ir a la oficina del banco a contarle nuestra historia al director del mismo. Tras muchos papeles, planes de negocio e historias varias, nos dará un TPV online. O no, depende de lo que él quiera. Seguramente tenga comisiones muy altas y haya que ir a más de un banco hasta que alguno nos ofrezca algo interesante.Normalmente los directores de oficina les chirría un poco la palabra «Internet» y lo ven todo con mucho escepticismo.
  • Utilizar PayPal: no necesitaremos hacer ninguna gestión y funcionará de forma fácil. Los usuarios pueden pagar en tu página aunque no tengan una cuenta de PayPal, porque pueden usar su tarjeta de crédito directamente sin registrarse. El problema: que las comisiones son enormes (3,4% más 0,35€ de extra). Si vendes tanto como dealextreme.com te bajan las comisiones un poco, pero siempre son altas.Si vendes cosas baratas, los 0,35€ matan gran parte del beneficio.

Lo ideal es empezar con PayPal y cuando tengamos algo tangible, podemos intentar implementar una pasarela de pago propia, que tendrá comisiones un poco mejores. Cuando le contemos la historia al del banco, al menos podremos darle datos reales de ventas, por lo que te tratará un poco mejor.


Escrito por .

10 razones para elegir InnoDB como motor de almacenamiento de MySQL

Escrito en MySQL, Tutoriales

Una de las preguntas más frecuentes al crear una tabla de MySQL es ¿qué elijo, MyISAM o InnoDB? Mucha gente decide de forma un poco aleatoria. Tanto MyISAM como InnoDB son motores de almacenamiento. El motor de almacenamiento es la capa de software que se coloca debajo del motor de consultas (la parte que se encarga de analizar y optimizar las consultas de SQL). Se encarga de hacer todo el trabajo «sucio» de localizar cada byte en el soporte físico, de asegurarse de que se cumplen las restricciones de integridad, de la concurrencia, etc.

Esta es la parte más compleja del sistema gestor de bases de datos, se compone de cientos de miles de líneas de código altamente optimizado. Cada motor de almacenamiento soporta unas características diferentes.

  • MyISAM: motor de almacenamiento simplificado. Trabaja con los datos de una forma más «relajada», con el objetivo de simplificar su uso y tratar de mejorar el rendimiento. Normalmente las tablas ocuparán menos espacio en disco. Suelen ser más rápidas para consultas de datos. Su contrapartida es que no sigue las 12 reglas de Codd, no tiene control de claves foráneas, transacciones, su control de la concurrencia es muy limitado, etc..
  • InnoDB: motor más sofisticado que cumple con las reglas del modelo relacional bastante a rajatabla. Por ello, garantiza una mayor durabilidad en los datos. En sus inicios se criticaba que añadía muchas características pero era mucho más lento que MyISAM. Esto ya no es un problema y en determinadas circunstancias le supera en rendimiento (sobre todo en modificaciones concurrentes de datos y en consultas indexadas por clave primaria).

Lo más importante es no mezclar tablas de distintos motores de almacenamiento. De lo contrario hacer un JOIN entre dos tablas de distinto tipo el rendimiento será pésimo. MySQL tratará de optimizarlo lo más posible, pero no podrá hacer milagros. Es posible que tenga sentido tener alguna tabla de un tipo distinto en determinadas circunstancias. Por ejemplo, podemos tener los datos vitales en tablas InnoDB y tener tablas con logs/registros en MyISAM porque no requieren de mucha complejidad.

A continuación detallaremos diez razones por las cuales InnoDB puede ser la opción correcta frente a MyISAM:

  1.  Soporte de claves foráneas. InnoDB permite relacionar tablas de forma implícita en la base de datos. Esto hará que la propia base de datos se encargue de eliminar inconsistencias en los datos. Con MyISAM tendríamos que «asumir» las claves foráneas, pero podríamos obtener registros inválidos. Por ejemplo, no podemos asegurarnos de que si borramos un producto, primero tengamos que borrar las categorías asociadas al mismo. Con MyISAM podríamos borrar un producto y la tabla de producto_categoria quedaría con registros huérfanos.
  2. Control de concurrencia de alto nivel. En MyISAM cuando una transacción modifica un registro de una tabla, la tabla entera queda bloqueada mientras se realice la modificación. Cualquier otra transacción que se realice mientras tanto tendrá que esperar. Eso puede crear cuellos de botella. Es muy común ver listas de procesos con cientos de INSERTs que están esperando a otro que se ha quedado atascado. Ante eso poco más se puede hacer que reiniciar el servidor o matar los procesos. InnoDB en cambio, proporciona un sistema de bloqueos a nivel de fila, lo que significa que solamente la fila que está siendo modificada queda bloqueada. Otras transacciones tratando de modificar la misma tabla podrían funcionar siempre y cuando modifiquen a otros registros. Modificar una tabla de forma concurrente es altamente probable. Modificar un mismo registro simultáneamente es mucho menos común.
  3. Bajo índice de tablas corruptas. Esto es debido en parte al punto 2. Debido al mal control de concurrencia de MyISAM, es muy habitual encontrarse con tablas corruptas si una transacción falla. En InnoDB se cumple la norma de que cualquier transacción llevará a la base de datos de un estado válido a otro estado válido. Muy raramente encontraremos una tabla InnoDB corrupta. Aunque cabe mencionar que reparar una tabla MyISAM es trivial mientras que en InnoDB puede llegar a ser una pesadilla.
  4. Soporte de transacciones. InnoDB soporta las transacciones. Es posible enviar una serie de consultas que se ejecuten de forma unificada. Así podemos crear aplicaciones con alto índice de fiabilidad, porque podemos asegurarnos de que no dejamos una operación a medio hacer. Cabe destacar que por defecto, el parámetro «autocommit» está activado, así que si queremos utilizarlas tendremos que o bien especificarlo (ver cómo) o desactivar esa opción.
  5. Índices clusterizados. Los datos se almacenan físicamente por orden (alfabético o numérico según se aplique) del valor de la clave primaria. Consultas que filtren únicamente por la clave primaria serán extremadamente eficientes, porque con saber el valor que buscamos, InnoDB con un par de operaciones ya puede saber dónde se encuentra el dato.
  6. Mejores opciones de replicación. La replicación consiste en copiar los datos de MySQL en varios servidores para repartir el trabajo a la hora de realizar consultas de datos. Al usar la replicación es fundamental que todos los nodos (servidores con copia de la base de datos) tengan una copia consistente de los datos, de lo contrario cada nodo podría devolver resultados distintos. Esto sólo lo puede garantizar InnoDB mediante sus transacciones y su avanzado sistema de bloqueos.
  7. Más escalabilidad. Las tablas MyISAM frecuentemente quedan bloqueadas y/o corruptas. En una tabla que almacene 200 registros esto puede ser un problema menor, porque repararla llevaría dos segundos. En una tabla con 20 millones de registros y que ocupe 2GB de espacio en disco esto es inaceptable. Podríamos dejar la aplicación inutilizada durante horas. Si predecimos que nuestra tabla crecerá mucho en tamaño o en requisitos de acceso, deberíamos considerar a InnoDB como opción.
  8. Motor ACID compliant. Estas son las siglas de Atomicidad, Consistencia, Aislamiento y Durabilidad. La base de datos siempre va de un estado válido a otro estado válido.
  9. Tablas sin límite de tamaño. En MyISAM cada tabla se guarda en un archivo por separado. Si la tabla supera los 2GB es posible que el sistema de archivos del sistema operativo no sea capaz de utilizarlo. InnoDB se encarga de que las tablas no tengan límite de tamaño. Para ello es posible que necesite dividir los datos en ficheros más pequeños. MyISAM no cuenta con esas características y tiene que depender 100% del sistema de archivos.
  10. Índices hash adaptables. Si un índice cabe en la memoria RAM y una tabla es consultada frecuentemente, es posible que InnoDB cree automáticamente un índice hash en memoria. Lo que hace es replicar el índice que se guarda en disco en la memoria RAM, de tal manera que los accesos tengan una velocidad muy superior. Es un sistema muy complejo que puede aumentar el rendimiento de las consultas significativamente.

Escrito por .

Publicar en el muro de Facebook con la nueva API y PHP

Escrito en Tutoriales

Usar servicios automáticos

Desde Sortea2 consideramos muy importante la sincronización con Facebook de los contenidos que aparecen publicados en la web. Es por eso que decidimos utilizar un servicio para que cada vez que se publicara un nuevo sorteo, se publicara automáticamente en el muro de Facebook.

Hay varios servicios que realizan esto, nosotros probamos con TwitterFeed y también con Ifttt. Ambos servicios son gratuitos y sencillos de usar, pero tienen un importante defecto: son muy poco fiables. Un día el TwitterFeed dejó de postear en el muro de Facebook y no había nada que se pudiera hacer al respecto. Pasó casi un mes y sin explicación aparente, volvió a postear cada nuevo sorteo publicado. Es por ello que decidimos darle un vistazo a posibles alternativas, eligiendo ifttt. Este servicio es muy interesante pero esta vez el problema estaba en que los artículos aparecían como muy resumidos en el muro de Facebook, y con un enlace en cada posteo.

Principalmente por la irregularidad de los servicios gratuitos, en los que no siempre se puede confiar, pero también por no tener todo el control de lo que se estaba publicando, decidimos intentar realizar esa sincronización por nosotros mismos.

Es este un problema que no todo el mundo va a tener, porque por ejemplo, si se tiene un blog de WordPress, hay servicios que automatizan la sincronización con Facebook gracias a plugins. En nuestro caso estas soluciones no nos sirven, pues tenemos un sistema propio para publicar los sorteos.

Y aquí aparece un tercer problema: todos estos sistemas antes mencionados dependen del RSS de sortea2, lo que provoca un importante retraso desde que se publica un sorteo en la página hasta que se incorpora al Facebook.

Y es que el RSS no se actualiza instantáneamente. Y los servicios revisan el RSS cada cierto tiempo, normalmente una media hora como mínimo. Es por estos retrasos que fácilmente la publicación de un nuevo sorteo puede resultar en su aparición en Facebook unas tres o cuatro horas después.

Así, decidimos echar un vistazo a la forma de realizar la publicación de forma directa, sin depender de servicios poco fiables.

Fijaros en la diferencia de personalización entre tres métodos de posteo:

Publicación automática con ifttt

Publicación automática con ifttt

Publicación automática con Twitterfeed

Publicación automática con Twitterfeed

Publicación automática totalmente auto gestionada

Publicación automática totalmente auto gestionada

API de Facebook

El primer problema que no se encuentra es que Facebook ha vuelto a cambiar la API de acceso externo, con lo que casi toda la documentación que uno encuentra en la red se refiere a la anterior API, que ya no funciona. Así, todas las búsquedas que se realicen en Google se deben limitar al periodo del último año. Todo lo publicado antes, por popular que fuera, no sirve para nada.

Así, uno se debe descargar la última versión de la API desde la página de desarrolladores de Facebook. Y luego con esa API vienen unos ejemplos, que para colmo no funcionan tal cual.

El concepto a entender a la hora de realizar nuestra publicación automática es que dentro de Facebook hay tres entidades diferenciadas que toman parte en todo esto:

  • El Administrador de la página, que es un usuario de Facebook, con nombre y apellidos.
  • La Página de Sortea2 dentro de Facebook, que es una página con uno o varios administradores.
  • La Aplicación de Sortea2. Es una aplicación que hemos tenido que crear, dentro de Facebook, para poder realizar posteos en el muro. Técnicamente con esta única aplicación ya se pueden realizar posteos en otras páginas y más acciones, pero si uno quiere postear en su propia página de Facebook, tiene que crearse una aplicación.

Así, si queréis postear automáticamente en vuestra página, vais a necesitar crear una aplicación de Facebook. ¿Cómo se crea una aplicación de Facebook? Hay muchos tutoriales y ejemplos por Internet que seguro que encontraréis. En el momento en que tengáis la aplicación, conseguiréis dos datos fundamentales:

  • Un ID de aplicación, appid.
  • Una clave secreta, secret key.

Con esos dos datos, ya podéis empezar a juntar las piezas. Lo siguiente es conseguir autorización de la página de Sortea2 para postear desde la aplicación que acabamos de crear. Esa aplicación podrá postear siempre y cuando se le hayan dado permisos muy amplios.

Para conseguir esos permisos, el mejor tutorial que existe es este. Hay que teclear unas urls en el navegador, con los datos de la aplicación (su ID y su clave secreta) y un tercer dato que es fácil de conseguir que es el identificador de Facebook de la página de Sortea2 (o vuestra página).

Los pasos a seguir son:

  • https://graph.facebook.com/oauth/authorize?client_id=APP_ID&scope=manage_pages,status_update&redirect_uri=http://www.facebook.com/connect/login_success.html (Se cambia el APP_ID por el que tengáis). Con esto nos logueamos damos permisos. Se obtiene un código.

    Dos notas sobre este paso:
    Primero: antes Facebook no exigía el parámetro scope = status_update, pero ahora es imprescindible.
    Segundo: el código que nos interesa aparecerá en la barra del dirección del navegador pero luego hace una redirección a otra página. Hay que estar atento para copiar ese código antes de que lo redireccione.

    A diferencia de lo que indica el tutorial, hay que exigir un permiso especial que es el de manage_pages.

  • https://graph.facebook.com/oauth/access_token?client_id=APP_ID&redirect_uri=http://www.facebook.com/connect/login_success.html&client_secret=APP_SECRET&code=CODIGO_PASO_ANTERIOR (De nuevo hay que cambiar, ahora el APP_ID y el APP_SECRET por los de vuestra aplicación y además el código obtenido antes).

    Con esto se consigue una cadena de texto que hay guardar como un tesoro: el access_token, un código que viene a decir «el administrador de Sortea2 autoriza a la aplicación Sortea2 a gestionar sus páginas».

Siguiendo los pasos de ese tutorial sin embargo uno consigue otra cosa: que el Administrador de su consentimiento a otorgar permisos a la aplicación. Porque según Facebook, una página no puede dar permisos a una aplicación directamente.

Estamos ya realmente cerca. Tenemos el access_token del administrador, pero nos faltan el propio access_token de la página. Porque si usamos el del administrador, los posteos no saldrían en el muro de Sortea2, sino en el de sus administradores, lo que tiene poco sentido.

Para conseguir el access_token de la aplicación ya hay que recurrir a la API de Facebook, con un sencillo script de PHP se puede obtener una lista de todos los access_token de todas las páginas en que esa persona sea administrador. Incluso directamente en el navegador se escribe:

https://graph.beta.facebook.com/USER_ID/accounts?access_token=USER_ACCESS_TOKEN

USER_ID es el ID de la persona administradora de la página, no el ID de la página de publicación. Los Facebook ids se pueden conseguir fácilmente desde este recurso.

El user_id es el ID que asocia Facebook a cada uno de sus usuarios. El user_access_token es el código tan importante que obtuvimos en el paso anterior. Con esto nos sale en pantalla una lista de todas las páginas que gestiona ese administrador y sus correspondientes tokens. Los copiamos aparte y guardamos, pues son la pieza final para escribir el código que necesitamos.

Después de todas estas dificultades ya tenemos las tres piezas que nos hacen falta:
APP_ID
APP_KEY_SECRET
ACCESS_TOKEN

Con esto ya se puede publicar cualquier cosa en Facebook, usando su API, en unas sencillas líneas de código:

$facebook = new Facebook(array(«appId» => APP_ID, «secret» => APP_KEY_SECRET));
$publishStream = $facebook->api(«/PAGINA_ID/feed», ‘post’, array(
‘message’ => «I love thinkdiff.net for facebook app development tutorials.»,
‘link’ => ‘http://ithinkdiff.net’,
‘picture’ => ‘http://thinkdiff.net/ithinkdiff.png’,
‘name’ => ‘iOS Apps & Games’,
‘description’=> ‘Checkout iOS apps and games from iThinkdiff.net. I found some of them are just awesome!’,
‘access_token’=> ACCESS_TOKEN ));

Así, basta con personalizar el código que tengamos. Donde guardamos nuestro sorteo, rellenamos los valores que queremos postear y los pasamos a esta llamada a la API de Facebook, que publica automáticamente el post en el muro, sin retrasos, sin intermediarios y con la personalización que nos guste darle.

Espero que este tutorial os sirva de ayuda, Internet está lleno de información irrelevante, creemos que esos links son los más relevantes, con algunas adaptaciones y cosas que no suelen decirte en ningún sitio:

  • Que tienes que pedir permisos de Administrador para la página.
  • Y que lo tienes que hacer para el usuario, no la página.
  • Que tienes que pasar el token cuando realizas una petición de posteo en el muro.

Mucha suerte con vuestras luchas con la API de Facebook.


Escrito por .

Generar sitemaps de millones de páginas

Escrito en Tutoriales

Los creadores de sortea2 siempre hemos tenido que tratar con el mismo problema en todas las webs que hemos tenido que realizar: generar los sitemaps.

En qué consiste un sitemap

Un sitemap no es más que un fichero XML en el que ponemos todas las URLs que tiene nuestro sitio web con el fin de que Google, Bing o el robot que quiera lo lea y sea capaz de indexar todo el sitio mucho más fácilmente de lo que lo haría normalmente.

A estas URLs les podemos dar además una prioridad, que es un número decimal de entre 0 y 1 que puede servirle como dato orientativo para el motor de búsqueda. No tiene lógica ninguna darle prioridad 1 a todas las páginas con la idea de que nuestras páginas indexen mejor porque el sistema no va así. Está hecho para diferenciar importancias entre diversas secciones del sitio web y cosas así. Luego será el propio motor de búsqueda el que determine qué vale la pena más o menos.

Un sitemap en su forma más simple es algo como esto:

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.google.com/schemas/sitemap/0.84">
<url>
  <loc>http://www.sortea2.com</loc>
  <priority>0.6</priority>
</url>
</urlset>

 

Dentro de cada <url> meteremos en <loc> el link en sí y luego su prioridad. Dentro del urlset irán todas las URLs.

Un sitemap así será fácil de generar con cualquier lenguaje que queramos (PHP, python, perl, etc.), puesto que simplemente es meter en un bucle todas las URLs e ir poniéndolas en ese formato XML.

El problema viene en que existe un límite de URLs que puede tener un sitemap. El límite está en 50.000 páginas y 10MB como máximo.

En este caso habrá que dividir los sitemaps en el máximo e ir separándolos mediante Sitemap indexs. Esto no es más que otro XML con la ruta de cada sitemap al que habrá que acceder.

Un Sitemap Index tiene la siguiente estructura:

<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.google.com/schemas/sitemap/0.84">
<sitemap>
<loc>http://www.sortea2.com/sitemap/sitemap1.xml</loc>
</sitemap>
<sitemap>
<loc>http://www.sortea2.com/sitemap/sitemap2.xml</loc>
</sitemap>
</sitemapindex>

 

Hasta aquí la breve explicación de en qué consisten los sitemaps.

Proceso habitual para generarlos

Habitualmente los generaremos mediante una tarea programada a una hora a la que veamos que nuestro tráfico baja considerablemente y ésta se encargará de escribir todo lo que sea necesario.

En PHP tenemos el problema de que por defecto los servidores suelen capar el máximo tiempo de ejecución del script a 30, 60 o 90 segundos, y si vamos a generar una cantidad grande de sitemaps implicando consultas de MySQL complicadas lo más normal es que nos quedemos cortos.

Para este problema habría que poner al principio del todo del script: set_time_limit(0); para que se le permita tardar todo lo que necesite. Aún así habrán servidores que tendrán fijado un tiempo máximo y no dejará de ninguna de las maneras cambiarlo.

Otra opción bastante viable puede ser usar Python o Perl; lenguajes mucho más veloces que PHP y que suelen venir instalados en hostings compartidos.

Primero se generarían los distintos sitemaps, cortando cada archivo cuando se llegue al límite y al final del todo se creará un índice de sitemaps conteniendo las URLs de todos los que acabamos de generar.

La manera de implementarlo ya variará dependiendo de cómo lo vayamos a hacer.

Consejos para generar miles de ellos

Si tienes que enfrentarte a la generación de una cantidad enorme de sitemaps, te convendrá tener en cuenta algunos consejos:

  • Escribe de golpe en los archivos con fwrite() pero sin usar flush(). De esta manera solo utilizaremos la memoria indispensable en cada momento.
  • Utiliza tablas temporales de MySQL cuando haya que hacer consultas complejas: una buena práctica que podemos necesitar es crear una tabla temporal. Si la consulta que va a generar el sitemap implica a muchas tablas, agrupaciones, eliminación de duplicados, etc. te puede convenir crear una tabla temporal que contenga simplemente los ids de los elementos a los que acceder de tal manera que luego las consultas que se hagan sean directas.

    Con este sistema el mal trago solo pasará una vez al crear la tabla temporal y aún así se ejecutará mucho más rápido que la consulta en sí porque no necesita generar ningún cursor. Las consultas directas sobre esa tabla serán tan simples que serán inmediatas.

    Lo óptimo es borrar la tabla temporal tan pronto como se pueda.

  • Parte en trozos la consulta que vas a tener que hacer: no es recomendable coger todos los datos de golpe e introducirlos en un cursor. Si tienes un millón de registros esa operación es inviable, porque tendrá que gastar una cantidad brutal de memoria (dependiendo de los datos) que realmente no va a valer para nada, porque cada vez solo vamos a leer un dato. Además, si tenemos que realizar esta consulta inmensa junto con algún tipo de ORDER BY, DISTINCT o algo así, es muy probable que agotemos la memoria interna de MySQL y nos dé un error interno grave de Incorrect key file for table ‘/tmp/#sql_7cd7_0.MYI’; try to repair it que quiere decir que no se ha podido generar la tabla temporal necesaria.

    La manera de partir en cachos el resultado de la consulta es meterla dentro de un while() que vaya cogiendo trozos del tamaño que veamos (50.000, 100.000 o lo que sea) con un LIMIT y que pare cuando ya no haya más datos.

    Así se irán escribiendo las URLs usando no demasiada memoria y se leerán de inmediato gracias a la tabla temporal.

  • Escribe todos los sitemaps olvidando saltos de línea y tabulaciones: Google no te va a premiar por escribir tus sitemaps completamente bien estructurados y legibles. Escríbelo todo en una sola línea continua con el menor número de espacios posible y así ahorrarás espacio en disco.

    Estamos hablando de miles de sitemaps, por lo que la diferencia si puede ser notable. En pocos sitemaps esto sería absurdo e innecesario.

  • Se pueden comprimir usando GZIP: si lo consideras oportuno puedes comprimir tus sitemaps usando GZIP, de esta manera ocuparán mucho menos y ahorrarás ancho de banda.

    Es de libre elección hacerlo o no. Por un lado tiene la ventaja de que ahorra disco duro y ancho de banda pero por otro tiene la desventaja de que te costará muchísimo más el generarlos porque la compresión tardará también lo suyo.

    Se pueden generar todos normalmente y luego lanzar un proceso que vaya comprimiendo uno a uno. No habría problema ninguno y serían perfectamente válidos.


Etiquetas: , ,
Escrito por .

Zonas horarias con PHP

Escrito en PHP, Tutoriales

Hace un par de años publicamos un artículo titulado Zonas horarias y PHP en el que explicábamos los entresijos del sistema que habíamos empleado para la programación de los sorteos que se realicen fuera de España.

En ese artículo se narra un mecanismo que proporciona el lenguaje de PHP para realizar los cambios de horario de forma eficaz y abarcando todas las opciones posibles. Sin embargo recientemente tuvimos que revisar todo el sistema porque había muchas quejas de usuarios que tenían problemas con sus sorteos programados que se realizaban a horas diferentes a las que ellos habían definido.

Al analizar la situación más en detalle pudimos ver que hay bastantes problemas en el sistema que indicamos en el artículo «Zonas horarias y PHP» que no tienen fácil solución.

Por un lado está el problema de que todo el empaquetado de zonas horarias y fechas de cambio está dentro de la instalación de PHP. Si un gobierno decide cambiar esa fecha, como ha sucedido recientemente con Argentina, la información de cambio está obsoleta y es sencillamente equivocada. PHP soluciona el problema creando una modificación a sus programas pero esa modificación se incluye en la versión más moderna de todas.

Ahora bien, uno no puede actualizarse la versión de PHP cada día. Sobre todo si se tiene la página en un hosting compartido, la actualización de versión la dictan los proveedores del servicio, uno no puede realizar dicho cambio. En nuestro caso, tenemos que vivir con una versión desfasada que tiene errores en las conversiones de hora para sorteos de Argentina y hemos tenido que implementar soluciones alternativas un poco artificiales. Oficialmente con la versión de PHP instalada, cuando queremos saber la hora actual de Buenos Aires no da una que está equivocada en dos horas.

Hace unas semanas se produjo el cambio de hora y también pudimos ver cómo horas antes de dicho cambio cuando se consultaba la hora estándar del sistema (mediante time(), tras establecer la zona horaria), la UTC (antigua de Greenwich) el sistema estaba dando un dato erróneo en una hora.

En conclusión, dar una actualización a la opinión que expresábamos hace dos años. No se puede establecer un sistema de cambios horarios que sea eficaz al 100% mediante PHP. La única opción es actualizar las versiones casi de continuo o crear un sistema artesanal donde ir indicando las diferencias horarias. El problema no es exclusivo de PHP y la culpa no es de ellos sino de muchos gobiernos que arbitrariamente modifican los políticas sobre diferencias horarias, no se ciñen a lo previsto años antes sino que realizan muchos cambios con efecto inmediato. En algunos casos también hay medidas de tipo político, como algunas regiones que pretenden distinguirse del resto del país con un cambio de zona horaria. Estos cambios no se reflejan automáticamente en las funciones de PHP.


Escrito por .