Sobre qué son las CORS o cómo tirarte de los pelos cuando aparecen.

Pongo la mano en el fuego que durante tu vida como programador has tenido que pelearte con las CORS alguna vez, verdad?

Si ya lo has hecho sabrás lo importantes que son y el por culo que dan, pero en cambio, si ni siquiera te suena este término pues… enhorabuena supongo.

Si no lo conoces y te dedicas al desarrollo web es algo que vas a necesitar saber en futuro así que dale.

Eso si, como siempre digo, en mi experiencia como desarrollador lo que mas me ha costado siempre es esto y las expresiones regulares. Esa cosas que se te atasca y no hay manera. Pues eso.

Pero no te preocupes si vas de nuevo porque conociendo los fundamentos de las CORS y a la mínima que hayas resuelto 3 errores de este tipo, te saldrán como churros 😉

 

¿Qué son las CORS?

A ver, para empezar la palabra CORS es una sigla de Cross-Origin Resource Sharing. Esto es, traducido al castellano Intercambio de recursos de Origen Cruzado. 

Pero no nos dice mucho. Vayamos a la wikipedia y a partir de ahí desarrollamos.

Intercambio de recursos de origen cruzado o CORS es un mecanismo que permite que recursos restringidos (como por ejemplo, las tipografías) de una página web puedan ser solicitados desde un dominio diferente por fuera desde el cual el primer recurso fue expuesto.

CORS define una forma en la cual el navegador y el servidor pueden interactuar para determinar si es seguro permitir una petición de origen cruzado.​ Esto permite tener más libertad y funcionalidad que las peticiones de mismo origen, pero es adicionalmente más seguro que simplemente permitir todas las peticiones de origen cruzado.

 

Creo que se entiende bastante bien pero para resumir consiste en que una página “no puede” cargar datos o elementos de otra página diferente.

Y pongo entre comillas “no puede” porque precisamente las CORS definen una política de seguridad que nos permite jugar con los recursos.

Obviamente todo esto tiene que ver con el desarrollo de páginas web y/o aplicaciones web. A la mínima que te pongas a hacer algo para la web vas a utilizar javascript si o si y lo sabes.

julio iglesias y lo sabes

Y en el fondo también tirarás de Ajax. Y si no piensa en todos los frameworks de front como funcionan en su base. Peticiones Ajax una y otra vez.

Pero antes de que apareciera el protocolo de las CORS no se podían cargar datos por Ajax en una página A desde otra página B.

Me explico.

Desde gorkamu.com yo no podía acceder a los recursos de forocoches.com, por ejemplo. Sólo se podía acceder a los recursos que estuvieran alojados bajo un mismo dominio. Es decir:

  • gorkamu.com/css/styles.css
  • gorkamu.com/js/form.js

¿Se entiende no?

Pues eso, que no se podía.

Aunque realmente había formas para “saltarse” esta limitación utilizando JSONP pero no eran genéricas desde luego…

 

¿Cómo funcionan las CORS?

Vale ahora pongámonos técnicos porque vamos a entrar con el tema del preflight y cómo afectan a las CORS.

Cuando una página web intenta conectar con otra para acceder a un recurso, ahí se está produciendo una petición HTTP. Las hay de distintos tipos pero todas ellas llevan cabeceras en su petición.

Aquí te explico un poco mas en detalle qué es y cómo funciona el protocolo HTTP.

Pues justo antes de que se llegue a realizarse la petición tu navegador automáticamente la intercepta para enviar antes el una primero.

Esta pre-petición automática es conocida porque se ejecuta bajo el método OPTIONS y no tiene cuerpo, sólo envía las cabeceras.

Las cabeceras o headers que se envían por parte del navegador le dan información al servidor sobre qué quiere hacer.

Así pues, en función de lo que nos responda el servidor después de esta primera pre-llamada, la petición original podrá continuar o por el contrario se bloqueará y arrojará un error.

prelight de CORS

Fíjate bien porque tal y como ves, este error de CORS también se produce por intentar acceder a un puerto diferente del 80 o 443. Aunque formen parte del mismo dominio.

Imagínate que abres Google Drive y haces una petición cualquiera. Por ejemplo el guardar un documento nuevo.

Si inspeccionas desde las herramientas para desarrolladores de tu navegador podrás ver algo tal que así:

Request headers en CORS

Esto que ves es la pantalla en la que puedes comprobar las peticiones HTTP que se están produciendo para esa página. Aquí puedes ir viendo una por una de qué tipo es y qué datos envía o recibe.

En la parte de Request Headers vemos las cabeceras que se han enviado en el preflight de la petición original. Hay varias de ellas pero quédate con las siguientes:

  • access-control-request-headers: authorization, x-goog-authuser
  • access-control-request-method: POST
  • origin: https://drive.google.com

 

La primera cabecera, access-control-request-headers, es una cabecera que se envía durante el proceso de preflight y le permite saber al servidor qué otras cabeceras HTTP van a usarse cuando se realice la petición. En el ejemplo se utilizan dos: authorization para autenticarse bajo Bearer o oAuth lo mas probable y la segunda x-goog-authuser para autenticarse contra Google.

La cabecera access-control-request-method le indica al servidor que métodos o acciones puede llegar a hacer la petición. En el ejemplo indica que solo va a ejecutar un método POST pero se pueden añadir tantas igual como de verbosa sea la API a la que quiere acceder.

La última cabecera, origin, le dice al servidor desde donde se realiza la petición. Si este host es válido para el servidor permitirá realizar la petición. Si por el contrario no reconoce el valor de la cabecera origin echará para atrás la request.

Ahora bien, si el servidor reconoce y valida estas cabeceras de la petición preflight podrá ejecutarse la petición original, sino no.

¿Pero y qué es lo nos responde el servidor?

Cabeceras CORS de respuesta
Cabeceras CORS de respuesta

 

Aquí las cabeceras de respuesta. Fíjate que devuelve con las mismas que hemos visto pero con alguno de sus valores ampliado. Por ejemplo la cabecera access-control-request-method, que a diferencia de lo que se enviaba en la petición, nos responde que acepta los métodos GET, POST y OPTION.

Esto es, para toda la aplicación los únicos métodos que pueda ejecutar cualquier petición serán esos tres únicamente. En el caso de que fuera una API a lo que se consulta, no sería muy verbosa si la entendemos como una RESTFull API…

 

¿Cómo habilitar las CORS?

Si ya has entendido como funciona esta política y ves el potencial que tiene probablemente quieras empezar a usarla ya.

Antes de nada piensa que si tu perfil es puramente backend estás de enhorabuena ya que la película de habilitar las CORS en tu API va a caer de tu parte si o si.

El gran trabajo lo tienes que hacer tu.

Y por parte de la gente de front tan solo hay que añadir las cabeceras a las peticiones y del resto ya se encarga el navegador (y el programador backend 😂)

Existe una página de referencia para saber cómo habilitar las CORS en diferentes tecnologías. La web en cuestión es esta, ya puedes guardártela bien en los marcadores…

 

Utilizar CORS en Apache

Apache, uno de los servidores mas utilizados en el mundo web. Aquí tienes un ejemplo de cómo usar esta política con este servidor.

Para añadir la autorización CORS a las cabeceras de Apache tan solo añade la siguiente línea dentro de la etiqueta <Directory>, <Location>, <Files> o <VirtualHost> de tu configuración

  Header set Access-Control-Allow-Origin "*"

Esta línea lo que hace es permitir las conexiones desde todos los orígenes. También puedes añadirla en tu .htaccess

Para asegurarte de que se ha aplicado correctamente la configuración puedes comprobarlo tirando la siguiente línea en la consola:

apachectl -t

Una vez que la veas aplicada tan solo te tocará reiniciar el servidor y listo!

sudo service apache2 reload

 

Añadir las CORS en NGINX

Para el que no lo conozca Nginx es otro servidor web bastante utilizado. Aunque también podemos configurarlo para ser utilizado como un Proxy-Inverso o como un balanceador de carga entre otras cosas.

Últimamente en mis desarrollos lo estoy utilizando mas que Apache incluso. Para habilitar las CORS en Nginx tienes a continuación la configuración necesaria.

#
# Wide-open CORS config for nginx
#
location / {
     if ($request_method = 'OPTIONS') {
        add_header 'Access-Control-Allow-Origin' '*';
        add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';
        #
        # Custom headers and headers various browsers *should* be OK with but aren't
        #
        add_header 'Access-Control-Allow-Headers' 'DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range';
        #
        # Tell client that this pre-flight info is valid for 20 days
        #
        add_header 'Access-Control-Max-Age' 1728000;
        add_header 'Content-Type' 'text/plain; charset=utf-8';
        add_header 'Content-Length' 0;
        return 204;
     }
     if ($request_method = 'POST') {
        add_header 'Access-Control-Allow-Origin' '*';
        add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';
        add_header 'Access-Control-Allow-Headers' 'DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range';
        add_header 'Access-Control-Expose-Headers' 'Content-Length,Content-Range';
     }
     if ($request_method = 'GET') {
        add_header 'Access-Control-Allow-Origin' '*';
        add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';
        add_header 'Access-Control-Allow-Headers' 'DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range';
        add_header 'Access-Control-Expose-Headers' 'Content-Length,Content-Range';
     }
}

 

Habilitar las CORS en PHP

Como bien he dicho mas arriba, Apache es uno de los servidores web mas utilizado y es por supuesto el servidor por excelencia para el lenguaje PHP.

De hecho un stack típico es el de LAMP, MAMP o WAMP que no deja de ser otra cosa que Linux o MacOS o Windows junto con Apache, Mysql y PHP por sus siglas….

Si por un casual no tienes acceso a editar la configuración de Apache siempre puedes habilitar las CORS en PHP añadiendo la siguiente cabecera:

 <?php
 header("Access-Control-Allow-Origin: *");

Esta cabecera la tendrás que poner antes de cualquier función que devuelva una respuesta.

 

Usar CORS con Express

El último de los ejemplos es habilitar esta política con Express. Un framework Javascript super utilizado principalmente para el desarrollo de APIs. Todo corriendo bajo Node claro está!

app.use(function(req, res, next) {
  res.header("Access-Control-Allow-Origin", "*");
  res.header("Access-Control-Allow-Headers", "Origin, X-Requested-With, Content-Type, Accept");
  next();
});

 

Con esto llegamos al final del artículo.

Espero que te haya quedado claro. A mi al principio me costó entenderlo y me tiraba de los pelos cada vez que me salía un error de estos al realizar una petición a través de Ajax a un recurso externo…

Pero no te preocupes, al segundo error que te salga de este tipo ya sabrás solucionarlo y sino siempre puedes preguntarme a través de twittah.

[xyz-ips snippet=”FAQS-GORKAMU-TW-YELLOW”]

A pastar!

Cómo sobrescribir una función de Woocommerce

En este artículo nos vamos a meter un poco en harina y vamos a programar un poquito y para ello vamos a aprender a sobrescribir Woocommerce.

Para el que no lo sepa, Woocommerce es un plugin para WordPress realmente inmenso y bien trabajado que nos permite crear una tienda electrónica en nuestra página web.

Con este plugin podemos gestionar los productos, las variaciones de esos productos, sus precios junto con su stock e incluso configurar productos digitales o incluso montar tiendas multidivisa.

Aunque como te podrás imaginar, esta vaga descripción se queda muy corta de las posibilidades que nos ofrece este sistema de comercio electrónico.

Woocommerce viene con muchísimas funcionalidades y además existen múltiples plugins y add-ons que nos permiten ampliar la funcionalidad básica del sistema.

Pero en este artículo no vamos a ver cómo instalarlo y configurarlo, no.

Hoy aprenderemos a sobrescribir Woocomerce, ampliar o modificar las funcionalidades que vienen por defecto o incluso los estilos que nos ofrece.

 

Sobrescribiendo estilos

Recientemente en el trabajo he tenido que sobrescribir una función de Woocommerce para añadir una clase a un elemento.

Obviamente lo podría haber hecho por jQuery pero ni es la forma correcta ni habría tenido contenido para sacarme este post de la manga 😛

Si todavía hay algún despistado que no sabe que significa la sobrescritura en la programación, siempre puedes darte una vuelta por este artículo en el que se ahonda sobre los conceptos de la programación orientada a objetos.

Pero básicamente consiste en redefinir el comportamiento de una función.

Ahora bien, el “problema” que tenía en el trabajo es que tenía que añadir una clase css personalizada a una de las templates de Woocommerce, concretamente a la template de las variaciones de un producto.

 

sobrescribir Woocommerce

 

Esta cajita gris de la imagen superior en la que aparece el precio y la disponibilidad de una variación se corresponde con la template que se pinta cuando aparecen variaciones.

Lo fácil y lo incorrecto hubiera sido buscar esa template dentro del core de Woocommerce y añadir ahí la clase que necesitaba, pero cuando se actualice el plugin de Woocommerce ese cambio lo iba a perder así que la solución pasaba por otro lado.

Y ese otro lado era sobrescribir la función de Woocommerce que pinta la variación.

Después de pasar un rato buscando en los ficheros del plugin por fin encontré la función que realizaba dicha tarea.

Dicha función se encuentra en wp-content/plugins/woocommerce/includes/wc-template-functions.php

Con esto ya localizado tan solo hay que copiar el código de la función que nos interesa y copiarlo dentro del archivo functions.php de nuestro child-theme y modificar lo que necesitemos modificar.

En mi caso solo he tenido que añadir la clase woo_single_variation tal y como puedes ver en el código siguiente:

Con este cambio ahora todas las variaciones contendrán la clase que me interesa. Cooool… 😀

 

Extendiendo la clase variación

Este ejemplo es para programadores que sean un poco mas pros pero el fondo de la cuestión es el mismo.

Coger lo que nos da WordPress y Woocommerce por defecto y añadirle nuevas funcionalidades.

El problema que tenía en esta ocasión es que necesitaba sacar todas las variaciones de un producto tengan o no tengan stock.

Según la documentación de Woocommerce la única función que se aproximaba a esto es get_available_variations() de la clase WC_Product_Variable.

Esta clase representa a una variación y tiene diferentes métodos para interactuar con ella.

Para mi disgusto, el método get_available_variations() sólo te devuelve las variaciones de un producto que tienen stock pero yo necesitaba todas, las que tienen stock y las que no…

¿Que hice?

Fácil, crear una clase propia que extendiera de la clase variación original y añadir un método para devolver todas las variaciones disponibles sin discriminar.

Te lo repito, si andas un poco perdido con tactos tecnicismos como sobrescritura, extensión y demás, date una vuelta por el curso de programación orientada a objetos, me lo agradecerás 😉

Esa es la clase que he extendido con el método que necesitaba y para hacer uso de ella:

Y con esto un bizcocho…

 

A pastar!

Entendiendo el funcionamiento del protocolo HTTP

Pongámonos técnicos para conocer y entender uno de los protocolos mas importantes y que se han vuelto esenciales en nuestra vida. ¿Protocolos de actuación en caso de emergencia? Bah eso son chorradas, hablamos de Internet y cómo el HTTP ha conseguido que dependamos completamente de el.

¿Qué narices es el protocolo HTTP?

Buena pregunta mi pequeño padawan. Y según su definición mas técnica de la Wikipedia:

HTTP, también conocido como Protocolo de Transporte de Hipertexto es un protocolo en la capa de aplicación del modelo OSI que se utiliza para transmitir prácticamente todos los archivos y datos de Internet, ya sean archivos HTML, imágenes, resultados de consultas u otras cosas.

Pues así es. Casi todo lo que recibes en tu smartphone, desde la foto de la chica que te gusta de Tinder hasta los mensajes de Whatsapp de tu madre llegan a través este protocolo.

Podríamos llegar a imaginar que el HTTP es como si fueran las carreteras del Interné pero al tratarse de un protocolo es mas bien un manual, un tutorial, una serie de reglas de cómo se tiene que comportar la información cuando viaja desde un punto A a un punto B.

Por lo general, HTTP se realiza a través de unos canales de comunicación llamados sockets TCP/IP.

Pero párate a pensar en cómo funciona el HTTP, no hace falta que entres en cuestiones técnicas, tan solo trata de imaginar que pasa cuando ves la foto de la chica del Tinder.

Cuando abres la aplicación en tu smartphone y quieres consultar el perfil de una usuaria tu móvil pide la información a un sitio indefinido de la “nube”, esa información se procesa y te llega una respuesta de ese sitio indefinido en forma de foto de perfil y demás información relativa a esa usuaria.

Esa información no te llega por arte de magia sino que alguien te la da cuando la pides.

Pues bueno siguiendo con el paralelismo, ya sea un navegador web o una aplicación, es un recurso que se comporta como cliente HTTP porque envía solicitudes a un servidor HTTP que se encarga de enviar respuestas al cliente.

EL GRAN ORÁCULO

A no ser que se indique otra cosa, toda esta información va a llegarte por el puerto 80 que es el estándar y el predeterminado que se utiliza en HTTP.

¿No sabes qué es un puerto? Imagínatelo como un gran puerto marítimo en el que van llegando barcos y el número indica el muelle de descarga y el tipo de mercancía que espera recibir. En el muelle 443 un barco traerá llaves, en el muelle 22 zapatos y en el muelle 80 libros y fotos.

Pues eso son los puertos informáticos (a muuuuuy grandes rasgos)

Una vez aclarados los conceptos básicos del HTTP hay que saber que existen diferentes formas de pedir y dar esta información.

Paradigma del cliente y del servidor

Para que toda esta red funcione es necesario que haya siempre alguien escuchando lo que necesitamos y aquí es cuando entra este modelo.

Como ya hemos visto antes, tu ordenador, tablet y smartphone sois los clientes y al otro lado hay un servidor que te facilita información. A nivel técnico cada uno de los extremos finales lo denominamos Hosts.

El cliente inicia el contacto con el servidor para solicitar un servicio, una vez que le llega la petición al servidor, este hará X operaciones con esa petición y al final de todo el servidor proporcionara una respuesta con la información pedida.

Puede ser un email, una página web, una fotografía o el acceso a un servicio expuesto.

Paradigma de entre iguales

También conocido como Peer to Peer o también conocido como “mierda, el eMule no me descarga”.

Cuando antes teníamos por definición una figura que siempre pedía y otra que siempre daba, con este paradigma todas las figuras piden y dan por igual.

Es como si en lugar de ir a una cafetería tradicional fueras a otra con autoservicio.

Con este paradigma se entiende que cada host puede entrar y salir de la red en cualquier momento, por eso pasamos a convertirnos en clientes y servidores a la vez.

Una ventaja crucial de este tipo de red es la escalabilidad.

Pero el protocolo HTTP también admite uno o mas protocolos de aplicación que utilizamos constantemente y sin saberlo.

Por ejemplo, cuando enviamos un email lo hacemos a través del protocolo SMTP. Cuando llamas a tu madre a través de Skype estas utilizando el protocolo de VoIP.

Así que para que termine de quedar claro, el protocolo HTTP puede utilizar muchos otros protocolos que van a definir el tipo de mensaje y la sintaxis que van a utilizar así como la información de los resultados.

Identificando aplicaciones

Cuando el proceso de comunicación tiene que ser realizado hay dos cosas que son importantes conocer.

  1. Dirección IP: es una dirección única y númerica del ordenador que va a ejecutar el proceso.
  2. Número de puerto: por dónde va a realizar la conexión. La combinación de dirección IP y número de puerto es lo que conocemos como socket.

Así pues volviendo al ejemplo del puerto marítimo y los barcos, cuando una empresa importa mercancías y contrata a un capitán de barco, este tiene que saber a que ciudad dirigirse y en que muelle atracar para cargar los productos para después saber a que ciudad de origen volver y en que muelle descargar.

Con esto, para que una conexión HTTP salga satisfactoria es necesario conocer los siguientes 4 datos:

  1. Dirección IP del cliente
  2. Número de puerto del cliente
  3. Dirección IP del servidor
  4. Número de puerto del servidor.

El protocolo HTTP utiliza el protocolo TCP para crear una conexión fiable entre el cliente y el servidor y todos los comandos que se utilizan dentro de este protocolo se envían en texto plano a través del puerto 80 (por lo general)

Hemos dicho antes que las direcciones IP son necesarias para establecer conexiones y también hemos dicho que son direcciones numéricas. Pero ¿cómo es posible que todos los días nos conectemos a facebook sin saber ni conocer a que dirección numérica tenemos que conectarnos?

Es una pregunta razonable ya que a lo mejor nunca en tu vida has visto una dirección IP.

Pues aquí es cuando entra otro actor mas en todo este panorama y se trata de los servidores de DNS. Algo así como el abuelete del pueblo que cuando paras con el coche para preguntar por una dirección sabe guiarte a la perfección hasta tu destino.

Un servidor de DNS se ocupa de traducir un nombre de dominio, en este caso facebook.com, a una dirección IP.

Si no existieran los servidores DNS las pasaríamos puta para navegar por Internet…

Las cosas se complican. Cuando antes solo tratábamos con el servidor para pedirle la foto de la chica con la entrada de los servidores DNS el camino hacia el recurso se alarga. Ahora tenemos que hacer lo siguiente:

  1. El cliente pregunta al servidor de DNS por la dirección de un nombre de dominio (wikibooks.org)
  2. El servidor DNS traduce wikibooks.org y le devuelve al cliente el valor 91.198.174.192
  3. El cliente monta una petición con esa dirección IP y la envía al servidor
  4. El servidor procesa la petición y devuelve una respuesta al cliente.

Internamente para una petición de consulta se hace lo siguiente:

GET 91.198.174.192/wiki/Communication_Systems/HTTP_Protocol HTTP/1.1

La primera parte de la consulta, la palabra “GET” es el comando HTTP a ejecutar. La segunda parte es la dirección URL del recurso que pedimos y la última parte es la versión del protocolo que va a utilizar la petición.

Cuando el servidor recibe la petición lo primero que va a hacer es respondernos si ha recibido bien o no la petición. Por lo general esperaremos siempre lo siguiente:

HTTP/1.1 200 OK

Esto significa que ha recibido la petición bien, pero si encuentras por ejemplo uno de los siguientes códigos ya puedes echarte a temblar…

HTTP/1.1 404 Not Found
HTTP/1.1 503 Service unavailable

Al igual que con la petición, la primera parte es la versión del protocolo a utilizar y la segunda parte de la respuesta es el número del código de respuesta junto con su mensaje en formato humano.

La web

Lo que conocemos como la Web o Internet no es mas que una gigantesca red interconectada de servidores que sirven recursos. Ya hemos comentado que esos recursos pueden ser de muchos tipos diferentes pero los típicos, las páginas web, no son mas que documentos escritos en HTML a los que accedemos a través de una URL.

Esquema básico del funcionamiento de la web
Esquema básico del funcionamiento de la web

Según los diferentes paradigmas, el usuario envía una solicitud de una página a un servidor dado a través de un navegador. Cada navegador tiene una firma a la que conocemos como User Agent que da información útil al servidor sobre quién ha hecho la petición.

Así pues, el HTTP es el protocolo de la capa de aplicación del modelo OSI que funciona con la tecnología Cliente-Servidor.

El servicio de transporte HTTP/TCP utiliza sockets para transferir datos.

El cliente inicia una conexión TCP utilizando sockets en el puerto 80 del servidor. A continuación el servidor acepta la conexión desde el cliente.

Nuevamente el cliente pide los recursos necesarios, en este caso los documentos HTML, las imágenes, los estilos… Una vez que el servidor le devuelve esta información, la conexión TCP es cerrada.

Como HTTP es un protocolo sin estado, no mantiene la información del usuario sobre las solicitudes anteriores. Así pues, este protocolo es muy simple pero si como programador quieres mantener el histórico de peticiones es posible que se te complique un poco la tarea.

Conexiones HTTP

Una página web está formada por una URL y por diversos objetos. Como puede haber uno o varios objetos o URLs, el tipo de conexión HTTP determina el orden en el que se solicitan los objetos.

Dado que la tecnología avanza a ritmo vertiginoso, el protocolo HTTP no podía ser menos y constantemente evoluciona para mejorar su rendimiento.

Existen diferentes tipos de conexiones HTTP:

  • HTTP/1.0: conexiones no persistentes. Esta conexión requiere que cada objeto sea entregado por una conexión TCP individual. Suele ser habitual un retardo en las entregas.
  • HTTP/1.1: conexiones persistentes. También llamadas HTTP keep-alive o HTTP Reuse. La idea es usar una misma conexión TCP para enviar y recibir múltiples peticiones y respuestas.

La principal diferencia entre una conexión persistente y otra que no es el número de conexiones TCP que se necesitan para transmitir los objetos.

Step by step de las conexiones
Step by step de las conexiones

Pero esto aún se puede enredar mas ya que dentro de las conexiones persistentes podemos encontrar la siguiente clasificación:

  • HTTP persistente sin pipelining: en este caso cada cliente tiene que esperar que el objeto previamente solicitado sea recibido antes de emitir una nueva solicitud para otro objeto.
  • HTTP persistente con pipelining: se permite que el cliente envíe todas las solicitudes de golpe por lo que el servidor las recibirá, las encolará y e irá devolviendo las respuestas una a una. Este es el método predeterminado en HTTP/1.1

Modelando el tiempo de respuesta

En todo este mundo de las conexiones HTTP entra en juego otro concepto clave y es el RTT. El RTT, conocido como Round Trip Time, es el tiempo transcurrido al enviar un paquete a un host remoto y recibir una respuesta.

Es un tiempo que utilizamos para medir el retardo en la red en un momento dado.

Este tiempo de respuesta indica el tiempo requerido para iniciar la conexión TCP y la siguiente respuesta o petición de vuelta que le cuesta llegar a un recurso.

Fíjate en la siguiente para entenderlo mejor.

Explicación de tiempo de respuestas durante el protocolo HTTP
Explicación de tiempo de respuestas durante el protocolo HTTP

Formato de los mensajes HTTP

Recapitulemos antes de desarrollar mas el tema.

Lo que conoces como Internet está basado en diferentes protocolos que indican cómo ha de enviarse la información.

Cuando tu quieres acceder a una página web, sigamos con el ejemplo de facebook, lo primero que va a hacer tu ordenador es enviar un mensaje a unos servidores DNS para preguntarles cual es la dirección IP de la página de facebook.

Una vez conseguida esa dirección IP, lo siguiente que va a hacer tu ordenador es enviar un mensaje a esa IP preguntando si puede conectarse, en caso de que el servidor conteste que si, que puede conectarse, tu ordenador va a enviar un segundo mensaje pidiendo el recurso solicitado y el servidor devolverá otro mensaje con ese recurso.

Bien, si hasta aquí esta todo claro pasemos a ver el formato de estos mensajes.

Existen dos tipos de mensajes, los mensajes de las peticiones y los mensajes de respuesta.

Mensajes de peticiones

Un mensaje de solicitud y/o petición tiene tres partes separadas por espacios, la primera el método o acción a realizar, la segunda el recurso pedido y la tercera la versión del protocolo que se va a utilizar.

El formato de los mensajes se escribe en ASCII para que pueda ser entendido por las personas.

Por ejemplo:

GET /path/to/the/file.html HTTP/1.0

El método GET es el mas utilizado, aunque no el único. Esto le indica al servidor que quieres obtener un recurso. La parte de la URL también se denomina URL de solicitud y el protocolo ha de estar siempre en mayúsculas.

A continuación puedes ver el esquema completo de un mensaje de petición.

Esquema de mensaje de petición HTTP
Esquema de mensaje de petición HTTP

Según el esquema, las líneas de cabecera o encabezado incluyen el tipo de navegador, el host, el número de objetos y el nombre del archivo y el tipo de idioma de la página solicitada. Por ejemplo:

Cabecera de una petición
Cabecera de una petición

Llegados a este punto tal vez te preguntes para que sirven el resto de campos del esquema del mensaje de petición ¿no?

Por ejemplo, cuando enviamos información a una página, al rellenar un formulario, esa información viaja en el cuerpo del mensaje bajo el método POST.

Y es que el protocolo tiene diferentes métodos o acciones a realizar.

Mientras que HTTP 1.0 solo tiene los métodos GET, POST y HEAD, la versión HTTP 1.1 tiene los métodos GET, POST, HEAD, PUT y DELETE.

Aunque esto ya se explicará mas adelante.

Mensajes de respuesta

Al igual que con los mensajes de petición, las líneas de respuesta de los mensajes HTTP también tienen tres partes separadas por espacios; la versión HTTP, un código de estado dando el resultado de la solicitud y una frase en inglés del código de estado.

Mensaje de respuesta HTTP
Mensaje de respuesta HTTP

Esta primera línea también se llama línea de estado.

Hay muchos códigos de estado que trataremos en un artículo a parte pero a continuación te dejo un par de ellos:

  • 200 OK: la solicitud se realizó correctamente y el recurso se devuelve en el cuerpo del mensaje.
  • 404 Not Found: el recurso solicitado no se encuentra.
  • 301 Moved Permanently: el recurso se ha movido permanentemente a otra URL.
  • 302 Moved Temporarily: el recurso se ha movido temporalmente a otra URL.
  • 500 Server Error: el servidor ha petado, revisa tus logs xD

Mecanismos para identificar al usuario en el servidor

El protocolo HTTP es un protocolo sin estado así que debería existir alguna forma de poder identificar a un usuario utilizando el servidor.

Ahora os voy a contar varias técnicas:

  1. Autenticación: siempre que el cliente solicita una página web al servidor, este mismo autentica al usuario pidiendo un nombre y una contraseña. Existe la necesidad de autenticación para que el servidor pueda tener control sobre los documentos. Esta autorización se realiza en la línea del encabezado de la solicitud.
  2. Cookies: también se utilizan para identificar a un usuario. Las cookies son pequeños trozos de datos que se guardan en el cliente y así el servidor es capaz de acceder a estas cada vez que necesita consultar esa información.

Pero… ¿Cómo funcionan las cookies?

Existen miles y miles de tutoriales hablando sobre las cookies pero un ejemplo claro para que lo visualices es el mensaje de la LOPD que te aparece en ciertas páginas obligándote a aceptar el uso de estas. Si lo aceptas cuando vuelvas a la web no volverás a ver el mensaje.

Eso está hecho con cookies.

Así pues las cookies tienen cuatro componentes principales:

  1. Línea de encabezado del mensaje de la respuesta HTTP.
  2. Línea de encabezado del mensaje de solicitud HTTP.
  3. Cookie propiamente dicha. Archivo almacenado en la máquina del usuario.
  4. Referencia a la web a la que pertenece.

Con esto podemos decir que las cookies las utilizamos para que una página web guarde información en el ordenador del cliente ya puedan ser unas credenciales, un carrito de compra u opciones de configuración entre otros usos.

Cuando vemos una cookie nos la podemos encontrar de dos sabores diferenes. Estas puedes ser persistentes o no persistentes.

Creo que es la diferencia es clara pero por si hay dudas, una cookie persistente es aquella que se almacena en el ordenador tanto tiempo como haya sido programada mientras que las cookies no persistentes desaparecen una vez que se cierra la página web de origen.

Pero gracias a estos mecanismos (cada vez mas puestos en duda) las páginas web, grandes empresas y gobiernos pueden trackear completamente al usuario así como sus hábitos de consumo digital.

Uno de los sectores que tanta mala fama ha dado a las cookies es el de la publicidad. Las empresas de anunciantes las han utilizado para obtener todos los datos posibles de los usuarios y así después poder segmentar los anuncios.

Cacheando la web con proxys

El principal objetivo del servidor proxy es satisfacer la solicitud del cliente sin involucrar al servidor web original. Este proxy es un servidor que actúa como un búfer entre el navegador del cliente y el servidor web.

El servidor proxy acepta las solicitudes del usuario y devuelve la información cacheada que pide el cliente. Si no encuentra el recurso que se está solicitando es cuando entonces se lo pide al servidor web original.

Funcionamiento de un proxy caché y GET condicionales
Funcionamiento de un proxy caché y GET condicionales

Los dos propósitos principales de un servidor proxy son:

  • Mejorar el rendimiento: a medida que va guardando el resultado de las solicitudes, cuando un nuevo cliente solicita un recurso que previamente ya se ha consultado es capaz de servirlo directamente desde la memoria caché del servidor. Esto hace que la velocidad de respuesta sea baja y la petición se pueda cumplir en menos tiempo.
  • Solicitudes filtradas: también se pueden utilizar para filtrar solicitudes, es decir, mediante un proxy se pueden restringir a los usuarios al acceso de un conjunto específico de sitios web.

Pero existen otros métodos para mejorar la velocidad de respuesta de las solicitudes y uno de esos métodos es el uso de los métodos GET condicionales.

Este método es el mismo que el GET visto hasta ahora, solo se difiere al incluir un campo en el encabezado con los siguientes posibles valores:

  • If-Modified-Since
  • If-Unmodified-Since
  • If-Match
  • If-None-Match
  • If-Range

Una solicitud del método condicional GET se satisfará siempre cuando cumplan las condiciones del nuevo campo del encabezado.

Este método se utiliza para reducir el uso de la red y para que las entidades de caché se puedan utilizar para satisfacer las solicitudes de los recursos si no han sido modificados y así evitar una transferencia innecesaria de datos.

Teniendo esto en cuenta, cuando un cliente pide una página web al servidor proxy, este comprueba que tenga la página pedida en su sistema de caché, comprueba la última fecha de modificación del encabezado y sirve el recurso.

Si la página pedida es modificada o cambia en el registro de caché el servidor proxy devolverá la página desde el servidor web principal. Una vez que el cliente ha recibido esta página modificada, el servidor web actualiza al servidor proxy para que así siempre tenga la última versión disponible.

Pues nada chachos, para ir terminando os dejo un par de recursos por si queréis ampliar información y si tenéis dudas podéis utilizar los comentarios o ponerme un tweet a través del siguiente banner 😉

Recursos:

https://en.wikibooks.org/wiki/Communication_Networks/HTTP_Protocol

https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html

https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol

[xyz-ips snippet=”FAQS-GORKAMU-TW-YELLOW”]

Hala a cascarla!

Mi top five de herramientas de programación

Es bien sabido que un buen profesional se apoya en diversas herramientas para cumplir con su trabajo. En este post te quiero enseñar cual es mi top five de herramientas de programación. Y no, no me valen los listos que puedan decir que el ordenador o la cafetera. Eso es una completa obviedad así que dejemos los chistes a parte y comencemos 😉

Las herramientas de programación que mas utilizo

Algunos son servicios online, otros son programas y otros extensiones:

  • Online JSON Viewer: empecemos por un clásico. Este visor de documentos JSON es una herramienta de programación que siempre tengo anclado en la barra de favoritos. De por sí su nombre ya lo dice todo, visor online de JSON, eso es todo, no esperes mucho mas. Viene de puta madre cuando quieres visualizar de una forma mas amigable un JSON. Por lo general yo lo uso copiando en la primera pestaña el contenido del documento y dándole a visualizar en la segunda pestaña aunque también tienes otras opciones como la carga de un fichero, borrar los espacios en blanco, formatear el documento, etcetera… Una de las cosas que mas me gusta de esta web es la forma de mostrar los datos en forma de árbol. La suelo utilizar cada dos por tres.
  • PHP Sandbox: pasemos al lado backend. Esta página te permite correr código PHP directamente desde el navegador. Ayuda mucho cuando quieres probar un snippet y no quieres estar metiéndolo en el proyecto antes de probarlo o tener que tener instalado todo un servidor web para probar pequeños cachos de código. Tiene casi todas las versiones de PHP y van desde la 4.4.9 hasta (en estos momentos) la 7.1.0.  Además tiene una biblioteca de funciones útiles que puedes utilizar a modo de chuleta y que están categorizadas según su tipología. También tiene tutoriales.
  • JSFiddle: Lo mismo que PHP Sandbox pero orientado al frontend. Páginas como esta hay miles pero yo definitivamente la elegí por su interfaz limpia. Te permite probar tus códigos HTML, CSS y Javascript y si te registras puedes versionar y compartir con tus compañeros los snippets que quieras probar. Una de las cosas que mas me gustan de esta herramienta es la transparencia de su roadmap de desarrollo. Tienen un enlace a un tablero púbico Trello (lo puedes ver desde aquí) en el que van anotando todas las mejoras que deberían desarrollar. Olé por ellos.
  • Postman: extensión disponible para Chrome que te ayudará a probar APIs. Pero no solo te permite probar APIs esta extensión, su poder va mucho mas allá y con ella podrás construir, realizar test y documentar todas tus APIs. Entre todas las funciones que tiene, Postman incluye un histórico de peticiones hechas, capacidad para montarte tus propias requests, agrupar tests por proyectos,  automatizar colecciones y en fin, un montón de cosas mas. Si en tu día a día trabajas con APIs y no la conocías ya estas tardando en descargártela 😉
  • PHPStorm: obviamente no podía faltar esta maravilla de la ingeniería. Hablar de las bondades de este IDE daría para una serie de artículos ya que después de un montonazo de años utilizándolo (realmente empecé con IntelliJ Idea) todavía no he descubierto todas sus funcionalidades pero os tengo que decir que debido a sus herramientas integradas, sus plugins y sus atajos de teclado no necesitas mas herramientas de programación para comenzar a realizar tu trabajo. Al principio se que la interfaz es difícil y tira para atrás, pero creedme de verdad, una vez que comencéis a utilizarlo no querréis trabajar con otra cosa, ni Sublime, ni Netbeans ni muchísimo menos Eclipse. Una maravilla vamos.

Faltaría por poner un control de versiones, en mi día a día el único que utilizo es SourceTree de MS….. jajajajaaja NO. Obviamente GIT pero no voy a explicarlo en este artículo ya que me estoy planteando sacar un curso dedicado a el.

Conozco muchísimas alternativas a los puntos anteriores pero después de años dedicándome a esto de los ordenadores, este es el pequeño set-up que me he conseguido construirme.

¿Y tu qué? ¿Conocías estas herramientas? ¿Si, no? ¿Conoces y utilizas otras tal vez? No dudes en dejar tu opinión en los comentarios o en twitter a través del siguiente banner 😉

[xyz-ips snippet=”FAQS-GORKAMU-TW-YELLOW”]

Hala a mamarla!

#3 Plataforma como Servicio: Heroku vs Amazon Web Services

No te equivoques,  Amazon Web Services, AWS de ahora en adelante, y Heroku, no son dos plataformas como servicio, solo una de ellos pero ambas nos van a permitir implementar, supervisar y escalar aplicaciones web y móviles de manera completamente diferente. Pero antes de seguir hablando vamos a recopilar un poquito de información.

¿Que coño significa Plataforma como Servicio?

Según la Wikipedia una plataforma como servicio o PaaS es lo siguiente:

Es una categoría de servicios en la nube que permiten a los clientes desarrollar, ejecutar y manejar aplicaciones sin la complejidad de construir y mantener la infraestructura típica asociada con el desarrollo y lanzamiento de la aplicación.

Vamos que es tener, en cierto sentido, a un DevOps, o chico de sistemas, en tu equipo. Aunque algo mejor ya que no vas a tener que tratar con otra persona y ni te vas a comer la cabeza averiguando que falla cuando se romper algo.

Delegas esas tarea o al chico de sistemas o a una plataforma como servicio. ¿Que quieres hacer una build y desplegar? Pues la haces y te olvidas de compatibilidades, de versiones y librerías que fallan.

Así de primeras suena muy bonito y actualmente en el mercado tenemos varias soluciones que nos cubra esta necesidad. Desde soltar los billeticos y contratar a alguien que se encargue de la infraestructura o utilizar uno de estos servicios.

Debido a su baje coste y su fácil gestión si estas montando una startup vas a elegir casi el 100% de veces una de las siguientes plataforma como servicio pero… ¿Cuál es mejor?

Heroku contra Amazon Web Services

Vale, si echas un vistazo a los productos y servicios que te ofrece Amazon Web Service posiblemente te de un tabardillo debido a la gran cantidad de palabras y cosas que no te suenan hay para elegir. Es normal que te pierdas.

Diferentes Productos AWS
Diferentes Productos AWS

AWS ofrece una amplia cantidad de productos en los que elegir por lo que es difícil hacer una buena elección si no sabes ni de que va todo esto ni que solución es la idónea para tus necesidades.

Y ni siquiera has comenzado a considerar Heroku!

Pero bueno, relaja las tetas, no te agobies que es normal que te sientas abrumado. Vayamos poco a poco para ver las diferencias entre estas dos Plataformas como Servicio.

¿Qué Plataforma como Servicio escoger para mi Startup?

Si buscamos una comparativa de Heroku y Amazon Web Services veremos un montón de artículos que hablan de los beneficios de uno y de otro. Pero, ¿es lógica esta comparación? Intentar cruzar estos dos productos no tiene mucho sentido por las razones que iremos viendo a continuación.

AWS Elastic Compute Cloud

El Elastic Compute Cloud, también conocido como EC2 es una infraestructura como servicio (lo sé, otro actor mas en los …como servicio) y es el buque insignia de los productos ofrecidos por Amazon.

Antes de que existieran estas herramientas cuando uno quería montar, mantener y gestionar todo lo que existe al rededor de una aplicación tenía que desarrollar la infraestructuras de servidores que soportase la aplicación en cuestión.

Pero, ¿qué pinta tiene una plataforma com servicio? Bueno pues en pocas palabras si trabajamos con una PaaS, vamos a tener que configurar y mantener los servidores virtualizados que ejecuten nuestra aplicación, vamos a tener que agregar instancias de bases de datos, elegir y configurar el sistema operativo y configurar un balanceador de carga para distribuir la carga a través de varios servidores de aplicaciones.

Además, debemos seleccionar la CPU y unas cantidades mínimas de memoria RAM y almacenamiento tales que satisfagan nuestras necesidades.

Ah! Y lo mas importante, tenemos que instalar un servidor de copias de seguridad por si hay algo que se va a la wea!

Elastic Compute Cloud nos proporciona sólo los “bloques de construcción”. Nuestra tarea es seleccionar los mejores bloques para nuestra aplicación y gestionarlos activamente, no solo tener que configurarlos.

En muchas empresas de desarrollo es bastante habitual encontrarse con la figura del DevOps que en grandes rasgos es el encargado de aprovisionar las instancias de EC2, controlar el despliegue de las aplicaciones y orquestar la infraestructura de los servidores.

Algo así como el que se encarga de decidir cómo estos “bloques de construcción” van a interactuar entre sí.

Pero bueno, ahora pasemos a ver qué es lo que nos ofrece Heroku.

Diferencias entre plataforma como servicio e infraestructura como servicio
Diferencias entre plataforma como servicio e infraestructura como servicio

Heroku, aquella plataforma como servicio con nombre japonés

Heroku es también otra plataforma como servicio (PaaS) basada en Amazon Web Services pero es totalmente diferente a Elastic Cloud Compute (EC2)

Es de vital importancia saber diferenciar entre las soluciones basadas en Infraestructuras como Servicio (IaaS) y Plataformas como Servicio sobre todo cuando al considerar deployar y mantener nuestra aplicación en una de estos dos soluciones.

Heroku es mucho mas sencilla de usar que AWS, es quizá demasiado simple pero hay una buena razón para que esto sea así.

Esta plataforma nos equipa con un entorno de ejecución y un conjunto de servidores de aplicaciones ya preparados. Además, nos beneficiamos de una integración perfecta con varias herramientas de desarrollo, un sistema operativo preinstalado y servidores redundantes.

Con esto no tenemos que “perder tiempo” pensando en la infraestructura tal y como haríamos con AWS EC2, tan solo escogemos un plan de subscripción y lo cambiamos si nos quedamos cortos.

Heroku se encarga convenientemente de los detalles. Por lo tanto, podemos apuntar todos nuestros esfuerzos al desarrollo de la aplicación.

Sólo se necesita un desarrollador web o varios desarrolladores para crear una aplicación y enviarla a Heroku usando un control de versiones como GIT.

Toda la gestión del despliegue de la aplicación se realiza a través de la terminal.

Así pues comparar Heroku con AWS EC2 es como comparar una tostadora con un microondas. Ambas máquinas las usamos para calentar (y a veces tostar) pan, pero funcionan de manera completamente diferente.

Así pues tanto con Amazon Web Service EC2 como con Heroku vamos a alcanzar objetivos distintos peeeeeero hay algo de lo que todavía no te he hablado y se trata de otro producto de Amazon que funciona igual que una plataforma como servicio y es el competidor directo de Heroku.

SERVICIOS AMAZON WEB SERVICE HEROKU
Ofrecido por Amazon Salesforce
Precio Pagas por lo que usas Pagas por lo que usas
Qué te ofrece Plataforma como Servicio (Elastic Beanstalk) e Infraestructura como Servicio (AWS EC2) Plataforma como Servicio
Concepto Plataforma lista para el deploy (Elastic Beanstalk) e infraestructura (AWS EC2) Plataforma lista para el deploy
Lenguajes soportados Ruby, NodeJS, Python, Go, Docker, PHP y .NET Ruby, Python, PHP, Clojure, Go, Java, Scala y Node.js
Capacidad de escalar Escalado automático en EC2 y Elastic Beanstalk basado en tiempos y métricas aunque puedes configurar el autoescalado antes de deployar Escalado manual a través de la terminal o del panel de administración
Disponibilidad geográfica En todo el mundo Estados Unidos y Europa
Características principales Aprovisionamiento, Balanceador de carga, Autoescalado, Monitor basado en métricas, múltiples configuraciones y plantillas de despliegue Aprovisionamiento, Rollback de base de datos y de aplicación, Escalado vertical y horizontal manual, Integración completa con Github y Monitor basado en métricas
Herramientas integradas Consola de administración, Terminal y AWS CloudWatch Heroku Command Line, Heroku Application Metrics, Heroku Connect, Heroku Status

Elastic Beanstalk, un nuevo jugador se unió a la partida

Si decíamos que usar AWS era complejo para hacer un deploy mientras que con Heroku no tanto, este nuevo producto de Amazon simplifica la manera en la que desplegamos nuestras aplicaciones en AWS.

Con AWS Elastic Beanstalk vamos a ser capaces de deployar la aplicación ejecutando comandos en una terminal proporcionada por AWS o utilizando la consola de administración y sin tener que preocuparnos de la gestión de la infraestructura, ya que de ello se ocupa Elastic Beanstalk.

Por lo general, no es necesario que configuremos el aprovisionamiento, el balanceador de carga o el escalado, aunque con esta herramienta es posible obtener acceso a la infraestructura si lo necesitamos.

También vamos a poder guardar múltiples opciones de configuración para nuestra aplicación y cargarlas cuando el entorno cambie a golpe de ratón.

Elastic Beanstalk utiliza instancias de EC2 para alojar su aplicación, por lo que la migración de AWS Beanstalk a EC2 es mucho fácil y eso es la leche.

Conclusión

Cuando te planteas escoger una de estar plataformas como servicio lo primero que tienes que considerar es el coste. ¿Qué es lo que mas va a costarte? ¿Manejar y gestionar la infraestructura por ti mismo o abstraerte de todo eso aunque el precio suba un poquito mas?

Así pues y a modo de resumen deberías usar AWS EC2 cuando:

  • Necesitas flexibilidad en la infraestructura para hacer el primer deploy de la aplicación
  • Tienes a mano a un (o unos) DevOps que te gestionen la infraestructura.
  • Si deployas constantemente nuevas versiones de tu aplicación
  • Tu aplicación exige grandes cantidades de recursos.

Y usar una solución basada en Plataforma como Servicio cuando:

  • Necesitas deployar lo que se conoce como MVP (Producto Mínimo Viable)
  • Necesitas mejorar la aplicación rápidamente después del feedback de los usuarios.
  • No puedes pagar a DevOps.
  • Tu aplicación no chupa tantos recursos.

Así pues, si estas montando una startup te recomiendo que tires hacia el camino de Heroku, aunque no es la única solución en el mercado de las plataformas como servicio pero si decides por alguna razón utilizar Amazon Web Service Elastic Cloud Compute asegúrate de que tienes a un buen DevOps porque si no vas a llorar como si fueras un chiquillo de 3 años 😛

Y nada, eso es todo. ¿Tu con cuál te quedas? ¿Has utilizado alguna vez una de estas herramientas? Si es así no dudes en dejarlo en los comentarios y si tienes alguna pregunta que sepas que puedes hacérmela usando twitter a través del siguiente banner.

[xyz-ips snippet=”FAQS-GORKAMU-TW-YELLOW”]

Hala a cascarla!

Incluir publicidad en una aplicación Ionic

Así es majos, este post es para enseñaros a empezar a monetiza tu nueva aplicación. Si has leído artículos viejos míos quizá ya sabrás a hacer una app con Ionic, habrás aprendido a meter un vídeo de Youtube en tu aplicación y tal vez hayas visto mis casos de éxito como este o este. Pues el siguiente paso es darse de alta en una red de anuncios, incluir publicidad en una aplicación y empezar a ganar pasta bitches.

Haciendo negocios con Admob

Lo primero que tenemos que hacer de todo es registrarnos en Admob. Admob es una empresa de “Mobile Advertising” por lo que si queremos ganar dinerico tenemos que enseñar anuncios en nuestra aplicación y esta empresa tiene muchos anuncios para enseñar, ah y es de Google jeje.

Nos venimos a esta url y realizamos el proceso de inscripción. Una vez que hayas terminado verás el panel de control en el que gestionarás tus bloques de anuncios y campañas.

Panel de control de Admob con el que podremos incluir publicidad en una aplicación
Panel de control de Admob con el que podremos incluir publicidad en una aplicación

Para poder incluir publicidad en una aplicación tendremos que conseguir un Ad unit ID, que es el código que identifica nuestra aplicación contra el sistema de anuncios. Para ello hay que hacer click en el botón:

Botón para añadir una nueva aplicación
Botón para añadir una nueva aplicación

Si tu aplicación no esta publicada ya en las tiendas oficiales te tocará hacerlo manualmente. Para ello hay que rellenar un formulario en el que se nos pide el nombre de la aplicación y la plataforma objetivo.

Registrando mi nueva app
Registrando mi nueva app

Una vez pases por las diferentes opciones para configurar el bloque de anuncios y ver la configuración opcional de analítica llega la parte de la implementación en el código de tu aplicación. Pero antes no te olvides de apuntar el código ca-pub, es el que se utilizará en la aplicación y aparece durante el proceso de creación del bloque de anuncios. Tiene una pinta tal que así:

Código con el que ganaremos dinerico
Código con el que ganaremos dinerico

Configuración necesaria para incluir publicidad en una aplicación

Si quieres incluir publicidad en una aplicación vas a tener que ensuciarte, meterte en código así que voy a ir picadito.

  • Abres la terminal (o consola) y te vas a la raíz de tu proyecto.
  • Te instalas el plugin cordova-plugin-admob escribiendo el siguiente comando y dejas que termine el proceso
cordova plugin add com.rjfun.cordova.plugin.admob
  • Si te quedas mas tranquilo puedes revisar los plugins instalados con el siguiente comando.
cordova plugin list
  • Añade el siguiente código a la función .run en el fichero app.js que lo encontrarás dentro del directorio www. También tienes una versión separada del script.
.run(function($ionicPlatform) {
  $ionicPlatform.ready(function() {
    if(window.cordova &amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp; window.cordova.plugins.Keyboard) {  
      cordova.plugins.Keyboard.hideKeyboardAccessoryBar(true);
      cordova.plugins.Keyboard.disableScroll(true);
    }
    if(window.StatusBar) {
      StatusBar.styleDefault();
    }
    if (window.device &amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp; typeof AdMob !== "undefined") {
          var admob_key = ca_app_pub_code = "AQUI_TU_CODIGO_CA_PUB";

          AdMob.createBanner( {
            adId: admob_key,
            position: AdMob.AD_POSITION.BOTTOM_CENTER,
            isTesting: false,
            adSize: 'SMART_BANNER',
            success: function(){
            },
            error: function(){
              console.log('failed to create banner');
            }
          });
      }
  });
})

Obviamente tienes que cambiar el valor de la variable admob_key, donde pone “AQUI_TU_CODIGO_CA_PUB” tienes que sustituirlo por tu código, el que has generado un poco mas arriba al registrar la aplicación en Admob.

Y eso es todo chicos. bueno, no del todo. Mientras estes haciendo pruebas en tu entorno puedes activar la variable isTesting, es un booleano así que sus valores son true o false. Esto sirve para enseñar un anuncio de prueba antes de ser enviado a las tiendas oficiales. No te olvides de dejarlo como false cuando compiles y vuelvas a enviar la app o sino no verás gallinicas 😛

Si tenéis alguna duda sobre cómo incluir publicidad en una aplicación o sobre cualquier otra cosa podéis dejarla en los comentarios o usar el banner de Twitter para preguntarme directamente. Venga gandules que es gratis.

[xyz-ips snippet=”FAQS-GORKAMU-TW-YELLOW”]

 

Hala a mamarla!

5 comandos GIT que deberías conocer

Que pasa chumachos!

Si estas leyendo esto en 2016 y no sabes que es GIT vas apañao. ¿Si te digo Sistema de Control de Versiones (CVS) te suena mas? ¿Si? ¿No? ¿No sabes no contestas? Bueno… en fin… vamos con una primera definición de la Wikipedia…

Git (pronunciado “guit”) es un software de control de versiones diseñado por Linus Torvalds, pensando en la eficiencia y la confiabilidad del mantenimiento de versiones de aplicaciones cuando éstas tienen un gran número de archivos de código fuente

Ufff…. esto tampoco lo deja muy claro, bueno intentaré realizar una explicación mas simple mediante ejemplos, ¿cómo si no?…

Imagina que estas trabajando en un proyecto junto a un compañero, escribes un pedazo de código, lo pruebas en desarrollo y lo subes a pre-producción. A la semana, tu compañero encuentra un bug en ese pedazo de código tuyo, lo encuentra y lo arregla pero no quiere borrar tu código porque cree que mas adelante puede refactorizarlo para hacer un código mas limpio así que lo comenta en bloque para que, aunque no sea funcional, poder revisarlo mas adelante.

Siguen pasando las semanas de desarrollo y las subidas semanales a pre y producción y obviamente tu compañero y tu seguís con esta practica de comentar código, llegará un momento en que no sabréis que versión del código tenéis cada uno y que versión de código esta desplegado en producción. Se trasca la magedia…

Pues esta realidad tan arcaica fue algo muy común en los desarrollos hasta que llegaron los Sistemas de Control de Versiones y aunque en un primer impacto está pensado para el código fuente y ficheros en texto plano no es algo determinante ya que puedes aplicarlo a cualquier tipo de fichero informático, aunque luego tengas que leer trazas en base64 al resolver conflictos xD

Así pues con GIT vas a poder mantener tantas versiones como quieras de un fichero pudiendo volver atrás en el tiempo para rescatar un cambio que hiciste incluso, y aquí viene lo chulo, podéis trabajar varias personas sobre el mismo fichero sin tener miedo a perder cambios o pisaros los unos a los otros.

Actualmente el BFS (Big Fucking System) de este tipo de software es GIT, es el rey de todos los sistemas de control de versiones y mas junto a la plataforma Github que sirve para alojar proyectos Open Source utilizando este sistema aunque por supuesto existen otros competidores en el juego como Subversion o SourceSafe aunque están a años luz del rey.

Así pues, una vez hechas las presentaciones vamos a ver los comandos git típicos que deberías conocer para desenvolverte con total fluidez a la hora de versionar tu trabajo y sobre todo qué es lo que puedes hacer con GIT.

 

Los comandos git de los campeones

Has escrito código nuevo y lo quieres guardar en el servidor para que el resto de los compañeros puedan descargar tu aportación, con la siguiente secuencia de comandos git lo puedes hacer muy facilmente.

git add fichero.php imagen.png script.sql
git commit -m 'Adding my first changes'
git push origin issue/rama

Con estos comandos lo que estas haciendo es añadir tres ficheros (fichero.php, imagen.png y script.sql) al área de preparación y le añades un comentario específico a ese commit, para que trackearlo y después puedas encontrarlo rápidamente si es que lo necesitas. Con el último comando, push, estas enviando tus cambios a la rama issue/rama que se encuentra en el servidor origin, nombre por defecto que le da GIT al servidor.

Estos comandos git te permiten enviar cambios al repositorio
Estos comandos git te permiten enviar cambios al repositorio

 

¿Fácil no? ¿Pero y si lo que queremos es descargarnos los cambios de un compañero que están alojados en otra rama del servidor? Pues con los siguientes comandos git podemos hacerlo…

git checkout issue/rama_de_tu_compi
git pull origin issue/rama_de_tu_compi

El primer comando te cambiará tu área de trabajo a la rama issue/rama_de_tu_compi y con el segundo traerá los cambios que no hayas descargado de esa misma rama.

Guay, el utilizar estos dos comandos a la perfección son la esencia de GIT ya que sino no vas a poder trabajar, vamos mas básico que esto no hay nada. Hacer cambios y confirmarlos y descargarse cambios. Fin.

Pero vamos a ver otros comandos git un poco mas complicados o de Pro Master, coño.

Imagínate que estas felizmente trabajando en tu rama issue/rama y has tocado varios ficheros pero justo ha entrado una incidencia crítica que tienes que resolver que exige que cambies de rama pero no quieres perder esos ficheros modificados, aunque tampoco quieres mandarlos al servidor porque aun no están preparados. Bueno pues GIT tiene unos comandos para guardar de manera temporal estos cambios y luego poder recuperarlos.

git stash
git stash list
git stash apply

El primer comando va a guardar esos cambios no confirmados de manera provisional en tu máquina local. Importante resaltarlo ya que no se envían al repostorio. Con el segundo comando verás un listado de los diferentes conjuntos de ficheros almacenados provisionalmente y correctamente etiquetados con un hash. El último comando es para volver a aplicar sobre la rama los cambios que habías guardado de forma temporal en tu ordenador.

Si ejecutas el stash apply como pone en el ejemplo, se aplicarán los cambios de todos los ficheros, si quieres solo aplicar algún cambio en concreto habrá que pasarle al comando el hash identificativo que antes veíamos con el stash list.

¿Hasta aquí bien verdad?

Ok, pues imagina que estas trabajando en el fichero fichero.php y en el momento de commitearlo la cagas y ejecutas un git add *, esto lo que hace es enviar todos los ficheros al área de preparación. Obviamente solo quieres enviar fichero.php y también se te ha añadido script.sql porque detecta un cambio que no quieres enviar. Okay, que no cunda el pánico.

Para sacar un fichero del área de preparación y deshacer los cambios ejecuta los siguientes comandos git.

git reset HEAD script.php
git checkout -- script.php

Ale, ya esta fuera del área y lo has dejado como si no lo hubieses modificado, ya puedes ir a por el commit 😉

jeje pero que exagerado, si hay un incendio primero hay que hacer un git add *
jeje pero que exagerado, si hay un incendio primero hay que hacer un git add *

 

Muy bien si ya has conseguido llegar hasta el punto de modificar algo y enviarlo al servidor, eso teóricamente significa que tus cambios están listos para ser incluidos en la rama master.

La rama master es la rama que mantiene el código o los cambios que van a producción, aquí se encuentra la versión oficial y definitiva de los cambios, con la rama master no se juega.

Así que si tus cambios ya están terminados y han sido aprobados acabarán aquí. Muy bien, haces el commit y el push y en el momento de solicitar un pull request para que incluyan tus cambios sobre master… Meeeck, error, aparecen conflictos y no se puede mezclar. Aaaahhh la puta, a todos nos ha pasado y da muchísimo por culo.

La principal causa de que no puedas mergear tus cambios sobre la rama master es que en el momento de realizar los cambios en tu máquina no estabas completamente actualizado y sincronizado con el código de master o lo estuviste en el momento de abrir la rama para comenzar a trabajar pero algún listo ha hecho cambios que tu no tienes por lo que te has quedado completamente desfasado. Anda que no jode…

Bueno pues es tan sencillo como ejecutar los siguientes comandos git.

git checkout master
git pull
git checkout issue/rama
git merge master
git commit -m 'Merging master branch into issue/rama to avoid conflicts'
git push origin issue/rama

Con esto lo que estas haciendo es volverte a bajar master y actualizarla para que una vez tienes todo el código sincronizado con el repositorio actualizar tu rama issue/rama mezclando el código de master con ella misma. Creo que se entiende bien ¿no? Los otros comandos git ya los hemos visto mas arriba…

Como todo, y a raíz de esto, unos te dirán que todas las ramas deben de salir desde la rama development y que únicamente saldrán desde master cuando se trate de un hotfix y otros empezarán todas sus ramas desde master… en fin, toda esta filosofía git depende de como este organizado el proyecto ya que la teoría de ramas da para mucho, muchísimo, para un artículo enterito casi casi xD

En fin, esto es lo bueno de trabajar con GIT, ofrece flexibilidad ilimitada para que cualquier equipo de trabajo pueda organizar y mantener su propio proyecto como le de la gana, aunque también te digo que hay unas recomendaciones y buenas prácticas que ya veremos en otro momento…

Pues nada chachos, hasta aquí mi artículo sobre comandos GIT y segundo listado del 2016, Gorka eres un bocazas si tenéis alguna duda sabéis que podéis dejarla en los comentarios o utilizar twitter a través del siguiente banner 😉

[xyz-ips snippet=”FAQS-GORKAMU-TW-YELLOW”]

 

Hala a chuparla!

Allahu akbar: cómo hacer una bomba lógica

Que no cunda el pánico!

Relajad las tetas que en este post no vamos a hacer exaltación al terrorista ni os voy a enseñar a hacer un artefacto pirotécnico. Si habéis entrado buscando ese tipo de información ya os podéis dar media vuelta e iros a freír espárragos. Lo que vamos a aprender en el post de hoy es a hacer una bomba lógica o mas concretamente una bomba fork y que afecta a sistema GNU/Linux.

Algo ya viejo y conocido en el mundo de la inseguridad informática junto a otros amigos como los virus, los gusanos o los rootkits pero que siempre es divertido de aprender y conocer su funcionamiento y que si se lleva a cabo con un poquito de ingenio, con tan solo tirar un par de caracteres podemos hacer muuuuucho daño.

Vamos a ver qué es una bomba lógica, vamos a aprender a programar una bomba fork y sobre todo vamos a ver cómo solucionarlo.

¿Qué es una bomba lógica?

Actuación de una bomba fork
Actuación de una bomba fork

Según la wikipedia:

Una bomba lógica es una parte de código insertada intencionalmente en un programa informático que permanece oculto hasta cumplirse una o más condiciones preprogramadas, en ese momento se ejecuta una acción maliciosa

Esta bomba la podríamos añadir al init.d de nuestro sistema Linux y joder para siempre el arranque del sistema operativo o al menos hasta que un experto le meta mano y consiga arreglarlo.

Vale, creo que ya ha quedado claro qué es una bomba lógica pero y una bomba fork que es sobre lo que estamos hablando hoy.. ¿qué es?

Pues una bomba fork sigue el mismo paradigma que las bombas lógicas pero se diferencia en que estas bombas son un tipo de ataque DOS que consiguen ocupar todo el espacio disponible de memoria RAM de un sistema.

Las bombas fork funcionan de la siguiente manera. Una vez que ha sido activada, el proceso padre que la maneja es capaz de crear procesos hijos que a su vez crean mas procesos hijos que a su vez crean mas procesos hijos y así hasta el infinito y de una manera recursiva. Estos procesos no reciben una señal SIGKILL por lo que no pueden ser matados. Como os imagináis y debido a esto el consumo de memoria RAM cada vez es mayor y mayor y la única solución para parar una bomba lógica es reiniciar el sistema.

Pues bien una bomba fork puede ser programada en cualquier lenguaje de programación, lenguaje de programación que no de maquetación, escribir HTML no es programar mamones 😉

Las siguientes líneas son un ejemplo de bomba fork escrita en C++

#include <unistd.h>

int main()
{
  while(1) {
    fork();
  }
  return 0;
}

Como leéis en el código, a no ser que se cumpla una condición, se va a estar ejecutando la función fork indefinidamente ya que la condición no se va a cumplir nunca en este snippet, te va a petar la memoria… ufff

Pero si algo me ha motivado a escribir este post sobre cómo hacer una bomba lógica es un snippet escrito en una sola línea en bash.

:(){ :|:& };:

¿Verdad que mola? Es muy gracioso, me recuerdan a caritas de patitos, pero patitos cabrones los muy joputas, no lo ejecutéis en vuestro en ordenador si no queréis tener que reiniciar el aparato…

Vamos a intentar desgranar esta línea para que quede mas clara.

Lo que en una sola linea contiene toda la lógica, si lo formateamos podemos empezar a ver lo siguiente:

:(){ 
  :|:& 
};:

La primera parte o línea del snippet formateado e identado se corresponde con la el nombre de la función, es decir, en lugar de llamar a nuestra función con un nombre literal la hemos nombrado con el nombre de los dos puntos.

Esto

:(){ 
}

Es igual a esto

bomba(){ 
}

¿Hasta aquí bien no? Ok

La segunda línea se corresponde con la llamada recursiva a sí misma haciendo uso de las tuberías UNIX pero sobre todo y lo mas jodido es el ampersand utilizado al final. Si recordáis las clases de Linux, sabréis que el uso de este símbolo después de la llamada de una función hace que el proceso se ejecute en segundo plano y se mantenga en constante ejecución hasta que termine o sea matado.

Así pues esto

:|:& 

Es igual a esto

bomba | bomba & 

Y para rizar el rizo, una vez que la ejecución de la bomba lógica ha terminado, vuelve a llamarse a si misma volviendo a iniciar todo el ciclo y volviendo a tocar los cojones xD

Por lo cual, el código desgranado y explicado queda de una forma que es mucho mas sencillo de leer y entender.

bomba(){ 
  bomba | bomba & 
};bomba

Ahora bien, si hemos sigo tan tontos de auto hacernos un ataque DOS mediante bomba lógica o hemos sido infectados mediante por ejemplo un script en el init.d tal y como decía antes, ¿cómo podemos parar una de estas bombas?

Mitigación y solución a bombas lógicas

Como decía antes, parar una bomba de este tipo es algo bastante difícil debido a la recursividad y a que tienden a ir ocupando todos los bloques de memoria disponibles hasta saturar completamente toda la RAM. Una solución que podría llevarse a cabo sería en ejecutar un script que se dedicase a ir matando procesos aunque puede no ser posible si no hay posiciones vacías dentro de la tabla de procesos o espacio dentro de las estructuras de memoria.

Si realmente queremos prevenir un ataque de este tipo, la mejor solución sería limitar el número de procesos que pueden ejecutar los usuarios. En el kernel de Linux existe una variable llamada RLIMIT_NPROC, que indica la cantidad máxima de procesos que se puede ejecutar. Si un proceso intenta llamar a la función fork y el usuario que es propietario del proceso ya tiene igual o más procesos que los indicados en RLIMIT_NPROC la llamada a la función fallará y se evitará la ejecución lógica de la bomba.

Bueno pues nada chavales, ya habéis aprendido otra cosa mas sobre vuestros sistemas, si tenéis alguna duda podéis dejarme un comentario o escribirme a Twitter a través del banner de abajo. Si ponéis en práctica esta bomba lógica que sea sobre vuestro propio ordenador o sobre una máquina virtual, no seáis hijoputas y ataquéis a otras personas, si lo hacéis yo no quiero saber nada…

[xyz-ips snippet=”FAQS-GORKAMU-TW-YELLOW”]

 

Hala a mamarla!

#2 Batalla de gallos: MongoDB vs MySQL

Seguimos con una nueva batalla, en este caso MongoDB vs MySQL. Vamos a ver que motor de persistencia es mejor y de entre las características de ambos cual ganará esta batalla de gallos.

Las bases de datos relacionales han sido el pilar de un montón de aplicaciones empresariales durante mucho tiempo y mas desde que se lanzó MySQL en 1995, esta ha sido la opción mas popular.

Ahora, sin embargo con la explosión de la minería de datos y el trabajo con grandes volúmenes de estos ha provocado que tecnologías en el campo de bases de datos no-relaciones hayan aparecido en el juego como requisito para el nuevo tipo de aplicaciones.

Así pues, bases de datos no-relaciones como MongoDB se utiliza para este tipo de aplicaciones, aumentando o reemplazando la infraestructura típica relacional.

¿Qué es MySQL?

MySQL es un Sistema de Gestión de Base de Datos (SGDB) Open-Source basado en entidades y relaciones. Si alguien no sabe que es el Open-Source no es nada mas y nada mas que código abierto, distribuido y desarrollado libremente. Cualquiera puede leer, utilizar y contribuir al código fuente de una aplicación Open-Source.

Pues bien, pese a ser software Open-Source, MySQL es mantenido y distribuido por Oracle pero si te apetece ver el código fuente de MySQL puedes forkearte algún repositorio de todos los que tienen en su cuenta de GitHub y echar un vistazo.

Tal y como hacen otros sistema de gestión de bases de datos, MySQL almacena los datos en tablas y estructuras utilizando un lenguaje específico para relacionarse y comunicarse con esos datos guardados. Este lenguaje se llama SQL (Structured Query Language). Como no es nada nuevo no voy a contar como utilizar SQL  sino que voy a dejar este tutorial de la W3SCHOOLS por si alguien viene de nuevas y si quiere conocer  además en qué se basa SQL, cual es el trasfondo técnico de cómo funciona, te diré que se trata del álgebra relacional, aquí tienes un paper introductorio sobre el cálculo y el álgebra relacional.

En diferentes trabajos (técnicos) que he tenido, he visto utilizar SQL no solo a informáticos sino también a gente de contabilidad y finanzas incluso al personal de marketing así que no es una mala idea que tengas unos mínimos conocimientos por si trabajas de forma directa o indirecta con ordenadores y volúmenes de datos.

En MySQL se definen tanto la estructura de la base de datos como las relaciones entre las diferentes entidades que van a existir según tus requerimientos dentro de un universo concreto de datos.

Si te cuesta visualizar la afirmación anterior o no la entiendes lo vas a ver muy claro con el siguiente ejemplo. Yo no sé si serás usuario de Netflix o no pero te voy a contar como funciona. La cuenta mas avanzada (y cara) del servicio de televisión bajo demanda permite mediante un único registro, un único email y una única cuenta bancaria o cuenta de Paypal ser utilizado hasta por cuatro personas diferentes.

Cuatro personas que van a acceder a la plataforma con sus propios dispositivos y que van a necesitar una cuenta de usuario para poder entrar. Si nos planteamos guardar este conjunto de datos podríamos hacerlo tal que así de una manera muy muy muy simplificada y sin tener en cuenta otras entidades y relaciones.

Relación de ejemplo en una base de datos relacionales como MySQL
Relación de ejemplo en una base de datos relacionales como MySQL

Como vemos aquí, tenemos la tabla de Usuario en la que almacenaremos datos relacionados sobre los usuarios, ¿lógico no? Un identificador que será un número único, el nombre de usuario, su email y su contraseña. Por otro lado tenemos la tabla Dispositivo en la que también tenemos un identificador, el tipo de dispositivo, su modelo y una referencia al usuario al que pertenece.

Tenemos así una relación, una relación 1:N en este caso, me explico.

Supongamos que el Rey de España es un viciado de las series y en un momento dado se hace una cuenta en Netflix. Al poco tiempo su mujer, la Infanta Cristina y Urdangarin se enteran y le solicitan un acceso a Felipe.

El Rey se conecta a la plataforma mediante su Mac Air, su mujer con un iPad, la infanta lo hace mediante su smartphone y Urdangarin desde una Smart TV. Así pues el conjunto de datos quedaría tal que así:

Vemos que el identificador de Usuario en la tabla Dispositivo es de 1 relacionándose así con el identificador de Usuario en la tabla Usuario. Con esto tenemos que la cuenta elRey se conecta a Netflix usando un Mac Air, un iPad, un Android y una LG.

Esto es lo que conocemos como bases de datos relacionales.

Aquí te dejo un curso completísimo sobre SQL de la Universidad de Standford.

¿Qué es MongoDB?

MongoDB es una base de datos Open-Source desarrollada por los chicos de MongoDB… y que se guía bajo el concepto de base de datos no relacionales. A diferencia de las bases de datos relacionales que exigían definir estructuras de datos fijas y estáticas que acababan tomando forma de tabla, en las bases de datos no relacionales los datos se guardan en forma de documentos en los que la estructura puede variar.

Así pues en uno de estos documentos podemos guardar  la información de la cuenta de Netflix del Rey junto a sus 4 dispositivos, pero además también podemos meter un conjunto de series y películas que le gusta a cada uno de los 4 dispositivos diferentes.

Y todo eso en un solo objeto.

Este tipo de almacenamiento junto a su forma de acceder y explotar los datos lo conocemos como NoSQL y es super rápido debido a que no tiene que ir a otras tablas a buscar información adicional para darnos una visión parcial o total de un universo de datos sino que cuando consultamos algo, todo lo referente a eso ya lo tenemos.

MongoDB utiliza esquemas de datos dinámicos, lo que significa que se pueden crear registros sin definir la estructura, tales como los campos o los tipos de datos de sus valores. Se puede cambiar la estructura de los documentos simplemente añadiendo nuevos campos o borrando los que ya tenemos.

https://gist.github.com/gorkamu/3305fd3e9977b1eabf2b95becc1b8d20.js

Los documentos no necesitan tener un conjunto idéntico de datos y la desnormalización es el pan de cada día de este tipo de bases de datos. MongoDB se diseñó para tener una alta disponibilidad y una gran escalabilidad por lo que su crecimiento horizontal es mas fácil y barato para los sistemas.

Así pues para consultar la información sobre el Rey de España lo haríamos tal que así:

db.Clientes.find({Nombre:"elRey"});

Accedemos a los datos utilizando JSON para hacer las consultas. Aquí tienes el link a la universidad de MongoDB para aprender mas como funciona este tipo de base de datos no relacional.

Terminología y Conceptos

Con esta tabla vas a ver como muchos conceptos de MySQL tiene su analogía con objetos de MongoDB. Estos son los conceptos típicos de cada sistema.

MySQL MongoDB
Tablas Colecciones
Registros Documentos
Columnas Campos
Joins Documentos embebidos o lincados

 

Comparativa de funcionalidades. MongoDB vs MySQL

Al igual que MySQL, MongoDB ofrece un rico conjunto de características y funcionalidades mucho mas allá de los ofrecidos en simples conjuntos de key-value.  Algunas de las cosas que puede hacer son las consultas Ad Hoc, indexar, hacer balanceo de carga o replicarse.

En la siguiente tabla se pueden ver las funcionalidades de MySQL enfrentadas a las de MongoDB.

MySQL MongoDB
Modelos de datos enriquecidos No Si
Esquemas dinámicos No Si
Datos tipados Si Si
Localidad de los datos No Si
Actualización de campos Si Si
Facilidad para los programadores No Si
Transacciones complejas Si No
Administración y auditoría Si Si
Distribución dinámica de datos No Si

 

Lenguaje de consultas

Ambos sistemas tienen un conjunto diferente de estructuras de lenguaje para poder consultar los datos. En la documentación de MongoDB y en la de MySQL encontraras amplia información para manejarte con estas bases de datos pero para muestra un botón (que asco le he tenido siempre a esta expresión)

Consultas típicas de MySQL

https://gist.github.com/gorkamu/35f6c2da75b6a4d1b286d10da79ca0d3.js

Consultas típicas de MongoDB

https://gist.github.com/gorkamu/4ea507a826703ba144703503523a2094.js

MongoDB vs MySQL: update queries performance
MongoDB vs MySQL: update queries performance

¿Cuándo utilizar MongoDB en lugar de MySQL?

Empresas de diferente tamaño y número de trabajadores están empezando a utilizar este tipo de bases de datos ya que les permite desarrollar aplicaciones mas rápido, manejar datos de muy diferente tipo y administrar aplicaciones de manera mas eficiente a escala.

Al utilizar bases de datos no relacionales como MongoDB eliminas la capa ORM, sistema de mapeo objeto-relacional, que se encarga de convertir los datos guardados en tablas en objetos dentro del código fuente, en Java los POJOs y en PHP los POPOs.

La estructura flexible de una base de datos no relacional significa que el conjunto y tipo de datos pueden crecer y evolucionar sin que afecte a los requerimientos de la capa de negocio.

También, las bases de datos NoSQL se pueden escalar de una manera relativamente sencilla y sin tiempo de inactividad a través de diferentes centros de datos distribuidos, proporcionando nuevos niveles de disponibilidad y accesibilidad en comparación con las bases de datos relacionales.

¿Cuando es mejor opción utilizar una base de datos relacional?

Aunque la mayoría de las aplicaciones modernas requieren un sistema flexible y escalable como MongoDB, hay casos de uso para el que una base de datos relacional sería mas adecuado.

Las aplicaciones que requieren complejas transacciones de datos como el sistema de un banco, en el fondo utilizan bases de datos relacionales, al igual que se dice sobre el COBOL…

Las bases de datos no relacionales no son un sustituto de las bases de datos relacionales, son un complemento que podemos utilizar para diseñar un sistema de respuesta ágil utilizando además Varnish como sistema avanzado de cache.

Volviendo con el ejemplo del banco, podríamos tener una primera capa que manejara datos a través de NoSQL  y que fuera la encargada de interactuar con el usuario y las distintas APIs y una segunda capa utilizando SQL y que se encargase de almacenar los datos bancarios cuando los usuarios hiciesen transferencias.

Entonces… ¿MySQL y MongoDB se pueden utilizar juntos?

Pues como he contado arriba con el ejemplo del banco, si. Pero existen muchísimos ejemplos de desarrollo híbrido. En la gran mayoría de casos se trata mas de saber cual es la herramienta concreta para tus necesidades.

Por ejemplo, muchas de las herramientas de ecommerce utilizan una mezcla de ambas tecnologías. Mostrar un catálogo dinámico de productos que tienen diferentes atributos es un buen ejemplo para usar la flexibilidad en la estructura y en los datos que nos aportan las bases de datos no relacionales.

Por otro lado, el sistema de pago del ecommerce, es probable que utilice bases de datos relacionales como motor de persistencia debido a las operaciones complejas que pueden darse en la lógica de negocio y debido al sistema de transacciones que nos brinda MySQL.

En otros casos, nuevos requisitos en la lógica de negocio empujan a las organizaciones a adoptar tecnologías basadas en MongoDB de cara a la próxima generación de sus aplicaciones internas.

Así pues, con estos ejemplos, es bastante normal pensar que MongoDB es mejor que MySQL debido a su modelo de datos flexible y su arquitectura escalable pero todo es cuestión de valorar las mejores herramientas que se adapten a tus requisitos y no adaptar una solución tan solo porque esta de moda.

 

Y con esto se acabó la segunda batalla de gallos de tecnologías. Deja un comentario o ponme un tweet a través del siguiente banner con las tecnologías que quieres que enfrente en la próxima batalla 😉

[xyz-ips snippet=”FAQS-GORKAMU-TW-YELLOW”]

Hala a mamarla!

#1 Batalla de gallos: Vagrant vs Docker

Desde hace un tiempo a aquí, Vagrant ha sido la solución por defecto para crear entornos de desarrollo que pueden ser fácilmente configurados independientemente de nuestra maquina y compartidos entre el resto del equipo de desarrollo. Existen muchísimos beneficios al utilizar maquinas virtuales frente a tener que instalar todo el software de desarrollo, librerías, dependencias y servidores en nuestra máquina. Los siguientes son un ejemplo de lo que podemos hacer:

  • Construir snippets de código totalmente independiente de la maquina en la que estemos trabajando.
  • Los snippets de código pueden ser compartidos y reproducidos automáticamente con facilidad.
  • Podemos parar y arrancar maquinas virtuales a nuestro antojo.
  • Hostear entornos se convierte en algo efímero y podemos destruir aquellos sitios que no se utilizan ya.
  • Ahorramos tiempo en configuración y ganamos en desarrollo.

Esto ha sido así durante los últimos años, sin embargo, tenemos un chico nuevo en el bloque, un competidor que ha ido ganando terreno poco a poco.

Docker es el chico nuevo y también corre maquinas virtuales pero trabaja de una manera fundamentalmente distinta. En este post quiero hacer una breve explicación sobre cuales son las diferencias entre Vagrant y Docker y sobre cómo instalar WordPress en cada uno de estos.

Si nunca has oído hablar de Vagrant, Docker, máquinas virtuales y entornos de desarrollo te recomiendo que le eches un vistazo a este post en el que hablo sobre Vagrant 😉

Comparación en grandes rasgos de Vagrant y Docker

Para empezar, Vagrant utiliza una arquitectura mucho mas sencilla que la de Docker. Usa maquinas virtuales para correr los entornos independientemente de la maquina anfitrión. Esto se hace utilizando lo que se llama virtualización mediante programas como VirtualBox o VMWare. Cada entorno utiliza su propia maquina virtual y es configurada mediante un fichero que se llama Vagrantfile. Este fichero le dice a Vagrant como tiene que configurar la maquina virtual y que scripts va a necesitar correr junto con su orden de ejecución en el momento de aprovisionar la maquina.

La contrapartida de este enfoque es que cada maquina virtual que creemos contiene no solo el código fuente que estamos desarrollando junto a sus librerías y dependencias sino que además contiene todo un sistema operativo huésped incrementando así en varias Gigas el tamaño de la máquina.

Docker sin embargo utiliza lo que se conoce como contenedores que alojan tu aplicación y todas sus dependencias pero que comparte el kernel (el sistema operativo) con el resto de contenedores.

Estos contenedores se ejecutan como procesos aislados en el sistema operativo anfitrión, pero no están vinculados a ninguna infraestructura especifica. Lo bueno de este enfoque es que los contenedores pueden correr en cualquier ordenador.

¿Cuál es la conclusión de todo esto?

  • Vagrant es mas fácil de entender y es mas sencillo de configurar y poner en marcha. Lo malo es que puede consumir muchos recursos en términos a memoria RAM y almacenamiento.
  • La arquitectura de Docker en cambio es mas compleja de entender y su configuración puede volverse una tortura pero es mucho mas rápido y consume mucha menos CPU y RAM utilizando a su vez menos almacenamiento que Vagrant.
Infografía Docker vs Vagrant
Infografía Docker vs Vagrant

Cómo configurar Vagrant

Una de las mejores cosas sobre ambos sistemas es el ecosistema que se ha creado a su alrededor. Debido al hecho de que los entornos de desarrollo se crean fácilmente con scripts, los desarrolladores de estos scripts los están compartiendo creando así repositorios donde podemos encontrar miles de Vagrant boxes y Docker images diferentes que podemos usar libremente en nuestros proyectos.

Para aprender a configurar Vagrant vamos a utilizar una box de Vagrant que se llama Varying Vagrant Vagrants (VVV) la cual tiene una configuración muy típica para el desarrollo en/de Wordpress.

Antes de empezar necesitarás tener instalado VirtualBox y Vagrant.

Existen varios plugins para configurar Vagrant que VVV recomienda tener instalado:

  • vagrant-hostsupdater: automáticamente actualiza tu fichero de hosts para poder acceder desde el navegador a las maquinas aprovisionadas.
  • vagrant-triggers: permite configurar Vagranta para que dispare scripts cuando utilizamos comandos como vagrant halt o vagrant destroy. Un ejemplo de trigger podría ser el realizar copias de seguridad de la base de datos.

Si ya tienes todos los prerrequisitos instalados vamos a clonar el repositorio de VVV:

$ git clone git://github.com/Varying-Vagrant-Vagrants/VVV.git vagrant-local

Una vez se haya clonado nos dirigimos al directorio para levantar la maquina.

$ cd vagrant-local && vagrant up

Prepárate un café y espera porque el aprovisionamiento de la maquina suele tardar un poquillo… Piensa que necesita descargar todos los ficheros requeridos y configurar el sistema operativo para que podamos empezar a utilizarlo.

Una vez que haya terminado el proceso deberías ser capaz de poder acceder a http://local.wordpress.dev y ver un WordPress nuevo. Personalmente te recomiendo que te leas el README.md de VVV para saber mas sobre cómo configurar y usar sitios en Varying Vagrant Vagrants.

Cómo configurar Docker

Para empezar a configurar Docker y trabajar con el lo primero que necesitas tener instalado es Docker Toolbox que te provee con no solo el cliente de Docker sino que incluso nos trae Docker Machine y Docker Compose, que te ayuda a especificar múltiples configuraciones de contenedores con un solo fichero.

Una vez lo hayas instalado, la primer cosa que tienes que hacer es configurar Docker a través de una de sus maquinaa virtuales. Docker la utiliza para correr el Docker Engine que se encarga de administrar y controlar cualquier contenedor que quieras correr. Para ello vamos a crear una maquina virtual en VirtualBox llamada “docker-vm”.

$ docker-machine create --driver virtualbox docker-vm

Una vez la maquina se haya creado ya podemos comprobar los detalles de la misma ejecutando:

$ docker-machine env docker-vm

Y deberíamos obtener una salida parecida a la siguiente:

export DOCKER_TLS_VERIFY="1"
export DOCKER_HOST="tcp://192.168.99.101:2376"
export DOCKER_CERT_PATH="/Users/gilbitron/.docker/machine/machines/docker-vm"
export DOCKER_MACHINE_NAME="docker-vm"
# Run this command to configure your shell:
# eval "$(docker-machine env docker-vm)"

Si te has fijado bien, te habrás dado cuenta de que son las variables de entorno del cliente de Docker que utiliza para poder comunicarse con Docker Engine, así que vamos a hacer lo que nos dice y corramos el siguiente comando…

# eval "$(docker-machine env docker-vm)"

Persistiendo la configuración

Cada vez que abras una nueva sesión necesitas volver a correr este comando ya que sus configuraciones no persisten. Para guardar estas configuraciones te recomiendo que añadas el comando al fichero ~/.bashrc de tu sistema. El fichero bash se ejecuta automáticamente cada vez que se inicia sesión en el equipo.

Por fin somos capaces de empezar a crear contenedores de Docker. Una cosa importante a señalar es que Docker corre un proceso por cada contenedor. Esto significa que técnicamente si estamos corriendo una configuración de LAMP (Apache, Mysql y PHP-FPM) todos y cada uno de ellos deberán ser ejecutados en sus propios contenedores.

Esto sin embargo, es solo un ejemplo de guía y en la gran parte de los casos nos será conveniente agrupar procesos en contenedores, por ejemplo, Apache y PHP podrían correr en un contenedor y Mysql en otro diferente.

Afortunadamente existen imágenes oficiales de Docker para el desarrollo en/de WordPress como por ejemplo esta.

El enfoque que vamos a utilizar es precisamente ese, configurar Docker para correr WordPress (incluye Apache y PHP) en un contenedor y Mysql en otro contenedor diferente.

Creando nuestros contenedores

Para crear el contenedor Mysql ejecutamos lo siguiente:

$ docker run --name wordpressdb -e MYSQL_ROOT_PASSWORD=password -e MYSQL_DATABASE=wordpress -d mysql:5.7

Podemos echar un vistazo a la documentación de Docker para ver qué es lo que hace cada uno de estos parámetros aunque aquí tienes un pequeño resumen:

  • Con el parámetro –name le estamos dando un nombre a nuestro contenedor, ¿obvio no? Si no lo especificamos se generará un nombre aleatorio.
  • Con el parámetro -e estamos especificando variables de entorno que serán usada por el contenedor. Esta es una forma muy habitual de pasar información al contenedor.
  • Le indicamos al contenedor que se ejecute en modo detached.
  • Finalmente especificamos la imagen del sistema operativo que queremos utilizar con el parámetro image:version. Si esa imagen no existe localmente, Docker la descargará.

Ahora vamos a crear el contenedor para WordPress:

 $ docker run --name wordpress -e WORDPRESS_DB_PASSWORD=password -v "$PWD/":/var/www/html --link wordpressdb:mysql -p 80:80 -d wordpress

Hay dos cosas que hemos utilizado para este contenedor y que no hicimos para el contenedor de la base de datos:

  • Hemos especificado un volumen para mapear nuestro directorio de trabajo contra el directorio /var/www/html de nuestro contenedor utilizando para ello el parámetro -v. Mapeando el directorio podremos editar los ficheros de WordPress.
  • Añadiendo el parámetro –link hemos linkado el contenedor a nuestro contenedor wordpressdb anterior y le hemos dado el alias de mysql. Esto le permite al contenedor de WordPress conectarse contra el contenedor de la base de datos.
  • Hemos configurado el puerto en nuestra maquina virtual.

Podemos comprobar el estado de nuestros contenedores corriendo el siguiente comando:

$ docker ps

Pues ya está, ya serás capaz de visitar la dirección IP de tu maquina de Docker en el navegador y ver la pantalla de instalación de WordPress. Para saber la dirección IP de tu Docker puedes ejecutar el comando:

$ docker-machine env docker-vm

Un buen punto sería añadir un nombre a la IP en tu fichero de hosts para no tener que estar tecleando la dirección IP todo el tiempo.

Bonus: utilizar Docker Compose

Correr comandos tal y como lo hicimos un poquito mas atrás puede ser un coñazo y ademas estar fácilmente expuesto al típico “error humano”. Para ello Docker Compose puede echarnos una mano permitiéndonos utilizar un solo fichero en el que definimos toda la estructura del entorno de desarrollo y luego solo lo ejecutamos con un solo comando, algo así a como trabajan los Vagrantfiles.

Vamos a crear el fichero al que llamaremos docker-compose.yml

wordpress:
  image: wordpress
  environment:
    - WORDPRESS_DB_PASSWORD=password
  ports:
    - "80:80"
  volumes:
    - ./:/var/www/html
  links:
    - wordpressdb:mysql

wordpressdb:
  image: mysql:5.7
  environment:
    - MYSQL_ROOT_PASSWORD=password
    - MYSQL_DATABASE=wordpress

Si te fijas en el fichero, hemos replicado los comandos que hemos utilizado pero en formato yml. Ahora, para correrlo necesitamos ejecutar lo siguiente:

$ docker-compose up -d

En conclusión, ¿cuál es mejor?

Al igual que con el resto de cosas de la vida, no siempre existe un “bueno” y un “malo”, un “correcto” y un “incorrecto”, un “mejor” y un “peor”. Todo depende de cuales son tus necesidades y de cómo lo vas a utilizar así de con cuál te sientes mas cómodo. Personalmente he intentado configurarme un entorno de desarrollo con Docker pero me di cuenta de que era demasiado dificil para las necesidades del desarrollo que estaba haciendo en ese momento. De momento estoy contento con Vagrant ya que es fácil y funciona bastante bien pero estaré atento a ver como madura Docker y ver si lo acabo metiendo en alguno de mis desarrollos 😉

Hala a mamarla!