Hoy vamos a jugar un poco con la tecnología Kubernetes. En su día ya hablamos del modo de contener-izar aplicaciones en contenedores Docker. Ahora vamos a dar el
Seguir leyendo
Es este artículo vamos a investigar sobre el tan archifamoso Internet-de-las-cosas o IOT, del inglés Internet Of Things. Vamos a tocar varias cosas, revisaremos la arquitectura de un tipico escenario de comunicación entre dispositivos, veremos el protocolo MQTT y sus características, instalaremos un servidor, y luego nos conectaremos a este. También haremos unas publicaci
Seguir leyendo
Siguiendo con la serie practica en Docker hoy vamos a darle una vuelta a Mysql sobre Docker. Veremos como nos permite muchísima flexibilidad, por ejemplo convivir varias bases de datos en la misma máquina. Esto es ideal por ejemplo para separar los entornos de PRE y PRO. En el anterior articulo de Docker ya dimos unas pinceladas de la instalación de Docker, asi que continuaremos a partir de ahí.
Para empezar debemos saber que Docker dispone de una plataforma con miles de imagenes disponibles para ser descargadas, llamada Docker hub.
Ya teniamos la web terminada, la habiamos subido a un repositorio y hasta aprendimos a desplegarla usando git hooks o jenkins. Pero un capítulo estaba pendiente: hacerla segura. Allá por 2018 Google empezó a penalizar los sitios no seguros, y los que no llevaban el encabezado https:// los marcaba con una advertencia de "sitio no seguro". Ahora considera el protocolo valido y por defecto al https, así que de cara al posicionamiento es crucial. Garantiza varias cosas, pero la principal caracteristica es que la web que muestra un candado en su direccion, es legal y relamente es quien dice ser. La segunda propiedad que ganamos al instalar un certificado es que cifra nuestar conexion, así la comunicación cliente-servidor queda protegida con el protocolo SSL/TLS.
Esto nos protege de ataques Man-in-the-middle. Consiste en que un atacante se situa entre el cliente y el servidor intrereceptando el trafico, espiando el contenido y hasta insertando su propio contenido sin que las dos partes puedan advertirlo.
Pues bien, ya tienes terminada tu pagina web. En tu entorno local tienes tu nueva flamante web, que te has currado con el framework de moda. Lo empaquetas en un zip o un tgz y lo "efetepeas" copias al servidor en producción, lo descomprimes y listo. Peeeero, a las 3 de la mañana nuestro cliente de Japon ha indicado que no se puede registrar nuevos usuarios. Al parecer la última versión del código es incosistente. Los tests, si es que había, no tuvieron en cuenta que los cambios en la bbdd aun no estaban desplegados. Así que pasaron por alto un campo nuevo de la tabla de usuarios que faltaba y que impide registrar usuarios nuevos.
Hoy hemos venido a jugar con Kafka o mejor dicho Apache Kafka, ya que se trata de un proyecto bajo el paraguas de Apache Foundation. No todo el mundo es consciente de la aportacion de esta institucion, con sus cientos de proyectos. Pues vamos allá, Apache Kafka, es un sistema de mensajes basado en un Patron Publisher/Suscriber, distribuido, particionado, resiliente y replicado. Veremos sus caracteriticas principales y despues como de costumbre montaremos una pequeña arquitectura con Kafka en un entorno local, con varios productors y consumidores. Para hacerlo lo más real posible plantearemos un entorno lo mas heterogeneo posible, con piezas en Python y en PHP (Si, PHP tambien sabe jugar con Kafka)
En un principio, nuestra empresa era pequeña, con unos poco servicios nos apañabamos. la monitorización se hacia de aquella manera o simplemente no habia, habia varios servidores que tenian varios roles y todo iba la mar de bien. En un momento dado la empresa empieza a crecer, y se le añade esto y aquello. Los sistemas van madurando, de tal manera que lo que en un principio era un sistema facil de desarrollar y mantener se convierte en una tarea imposible. Tenemos un sistema muy heterogeneo, con partes en Java, otras partes en ASP y las partes mas actualizadas en PHP o Python, cualquier cambio supone un desafio, posiblemente parada de servicio, lo que vemos aqui:
Seguir leyendo
Llevo un tiempo queriendo hacer algunas pruebecillas con el tema de los proxys, los proxys inversos, balanceadores de carga, etc y hoy por fin de la mano de Docker vamos a montar un pequeño sistema en local, en muy pocos pasos y ultrafacil.
Antes de liarnos a descargar imágenes y tal vamos a dar un paso a tras y ver qué es realmente un proxy inverso y en que se diferencia de un proxy normal. Conceptualmente son bastante parecidos pero hay unas diferencias sutiles. Podríamos decir que la diferencia mas importante es a quien da servicio. Empezaremos con un proxy. Pues un proxy es una pieza intermedia entre un usuario y un servicio en internet que cachea o filtra ciertos contenidos dependiendo del tipo de usuario o tipo de categoría del servicio. Imagina que un empleado en un empresa decide que es buena idea acceder a Facebook en horario laboral. El proxy detectaría la categoría de ese empleado y sus privilegios asociados y podría prohibir el acceso a este servicio. Por otro lado imagina que ciertos empleados acceden a la web corporativa de su filial en Japón, y tras la primera consulta el proxy guardaría una copia de dicha web para que el segundo empleado no tuviera que esperar a que se descargue todo el contenido desde Japón.
Seguir leyendo
Hoy os voy a hablar de Docker. Llevaba muchisimo tiempo queriendo escribir sobre esta tecnología, pues vamos allá. Docker es relativamente joven, de 2013, en muy pocos años se ha convertido en el estandar de facto, con un gran futuro por delante. Se trata de una tecnología que facilita de un modo extremo ciertos procesos, los despliegues, el testeo, la escalabilidad, la resiliencia (me encanta esta palabra ;^)), etc. Vamos a definir qué es Docker, pero antes vamos a decir lo que no es. Docker no es virtualización, como puedan ser VMware, KVM o VirtualBox. Antes de continuar con lo que es o lo que no es, vamos a dar un paso pasa atras para entender en qué consiste la virtualizacion.
Tradicionalmente el departamento de sistemas de una empresa tenía toda su infrastructura, como suelen decir fuera, on-premise, o in situ, en el CPD. La virtualización vino a dar respuestas y soluciones a problemas a la hora de permitir múltiples sistemas operativos corriendo en la misma máquina . La virtualización no es más que la creación, a traves de software de una emulacion de un recurso hardware. El hipervisor explota la capacidad de ciertos ordenadores, no todos lo permiten, de virtualizar los recursos, el procesador, la memoria, los interfaces de red, etc, de la máquina. Se debe elegir que proporción queremos que se asigne a la máquina virtualizada, cantidad de GB de memoria o nucleos de CPU. De este modo permiten ejecutar más de un sistema operativo en la misma máquina simultaneamente sobre ese hardware virtualizado.
Seguir leyendo
Hasta ahora, gran parte de la autenticación en sistemas se hacía por variables de sesión y cookies, de tal manera que se almacenaban estas en el lado del servidor creando un entorno relativamente robusto. El inconveniente es que esta arquitectura tiene un problema con la escalabilidad al tener que registrar en bbdd cada login del usuario.
Bien, entonces ¿que aporta JWT? Pues resumiendo mucho: el almacenamiento del token en el cliente. El proceso es sencillo, el usuario se loga en el servidor por medio de una pareja clave-contraseña o a traves de un proveedor de servicios externos, tipo Google, Facebook, etc. Tras esta autorización se construye un token con una serie de campos, especificamente para este usuario, hora, rol, etc. Tras la creación del token éste será empleado en cada operación que se haga al servidor.
Esta manera de autenticarse contra un servidor encaja con la arquitectura REST, haciendo que nuestro servicio web esté completamente sin información de estado: stateles. Entonces al almacenar toda la información de sesión en el cliente nuestra arquitectura se vuelve escalable sin afectar al rendimiento. Otra de las virtudes de un servicio web de este tipo es que se desacopla del cliente, así que nuestro servicio puede consumirse por igual, desde una aplicación de escritorio, un movil o una web.
Entonces, al tema. Un token que forma tiene, de que está compuesto? ¿que es eso de JWT? pues JWT responde al acrónimo Json Web Tokens, éste está dividido en tres substrings separados por un caracter punto y podria tener el siguiente aspecto:
Seguir leyendo
Como todos los frameworks, Codeigniter puede trabajar con Phpunit para poder desarrollar una plataforma de testeo de nuestra aplicación. En este articulo vamos a hablar de como instalarlo y configurarlo. Para empezar necesitaremos ambos instalados, CodeIgniter y PHPunit. El primero lo descargaremos de la web en un comprimido, no tiene ninguna ciencia, se se descarga, se descomprime y listo. El segundo lo instalaremos via composer. Lo primero es crear nuestro archivo composer.json. Este archivo sera el que alimente el comando composer, que tendrás que instalar. si ya existiera el archivo json solo faltaria asegurarse de que tenemos la linea con la version adecuada de phpunit
{
"require-dev": {
"phpunit/phpunit": "4.* || 5.*"
}
}
Una vez creado el archivo en el raiz de nuestro proyecto le damos a composer:
Seguir leyendo
En esta entrada os voy a dar unas pinceladas, el ABC imprescindible para poder manejarse con GIT. Antes de empezar os contaré un poco de historia sobre el Git. Allá por 1991, Linus Torwalds andaba con el desarrollo del kernel de Linux. Este proyecto se llevaba de forma colaborativa por un conjunto de personas que contribuian desinteresadamente al mismo. Hasta 10000 personas y mas de 1000 empresas llegaron a participar en el proyecto. Para poder coordinar a este equipo de desarrollo distribuido por todo el mundo rapidamente se hizo necesaria una herramienta para colaborar.
El 25 de agosto de 1991 Linus Torwalds publicó en una entrada en las newsreaders del grupo comp.os.minix lo siguiente:
Hello everybody out there using minix -
I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu) for 386(486) AT clones. This has been brewing since april, and is starting to get ready. I'd like any feedback on things people like/dislike in minix, as my OS resembles it somewhat (same physical layout of the file-system (due to practical reasons) among other things).
En esta entrada os voy a hablar del uso de Apis de Google. Google tiene infinidad de servicios disponibles para ayudarnos en nuestros desarrollos, Google Webmasters, Google Analitics, Mapas, History location, etc . La api que vamos a usar es PageSpeed, un servicio que ofrece Google para poder averiguar el pagerank de una web. Para hacerlo más interesante crearemos un servicio dentro del contenedor de servicios de una aplicación Symfony y lo llamaremos desde nuestro controlador. Este servicio nos da una serie de datos, como velocidad, recursos, infracciones, errores. Aquí teneis la dirección del servicio para ver que ofrece https://developers.google.com/ speed/pagespeed/insights/ Si entramos y revisamos esta misma web, veamos lo que nos dice:
No esta mal del todo: un 90/100, alguna cosa a revisar, muy interesante. Por curiosidad lanzamos al mismo Google y nos da un 97/100.
Empezaremos por definir nuestro servicio en el archivo de configuracion services.yml.
parameters:
# parameter_name: value
pageRank.class: daniel\D1Bundle\Services\CurlService
services:
my_api_call:
class: "%pageRank.class%"
arguments: [url]
Excelente, ya tenemos nuestro servicio configurado, al que hemos llamado my_api_call, que invocará a la clase definida en el parametro pageRank.class con valor CurlService, declarado dentro de mi bundle. Muy bien, ahora nos vamos a la carpeta de servicios dentro del bundle donde éstos se alojaran:
memcache vs memcached: 10000 keys
memcached set: 0.91661500930786
memcached get: 0.86234307289124
memcache set: 1.0546097755432
memcache get: 1.0519700050354
Uno de los aspectos poco usados y mas oscuros de la programacion PHP es la funcionalidad que nos provee la palabra reservada Static. En esta entrada hablaremos de la palabra reservada Static y del operador de resolucion de ambito "::". A este operador tambien se le conoce por el fantastico e incomprensible nombre Paamayin Nekudotayim, que literalmente del hebreo quiere decir doble pareja de dos puntos. Dicho esto puedes olvidar su nombre pero es una frikada digna de contar entre cervezas.
Bien, una cerveza... digo.. la palabra reservada Static aplica a variables en una funcion o dentro de una clase, a variables miembro o a los metodos. Veremos todos ellos con algun ejemplo que nos dejaran claro su uso.
Entonces, ¿que es una variable estatica? Una variable estatica es una variable que solo existe en un ambito de una funcion pero que mantiene el valor cuando la funcion termina su ejecucion. Es decir recuerda su valor la proxima vez que se llama a la funcion ¿Como? Si ha terminado su ejecucion, deberia destruirse!! Veamos un ejemplo:
function mifuncion(){
static $a = 1;
$a *= 2;
echo $a.'\n';
}
mifuncion();
mifuncion();
mifuncion();
Vamos a describir en este articulo la creacion de un servicio web basado en peticiones REST con un servicio de Symfony. A lo largo y ancho de la web encontraremos infinidad de servicios parecidos que entregan los resultados en JSON, XML o texto plano. Los resultados de una operación pueden venir organizados en arrays listo, por ejemplo, para poblar un desplegable mediante una operacion AJAX. Podemos ver como Twitter tiene servicios muy parecidos al que vamos a crear que devuelven los resultados via json. Por ejemplo podemos ver la info que devuelev para un usuario :
https://api.twitter.com/1.1/users/show.json?screen_name=rsarver
{
"profile_sidebar_fill_color": "F8FCF2",
"profile_sidebar_border_color": "547980",
"profile_background_tile": true,
"name": "Ryan Sarver",
"profile_image_url": "http://a0.twimg.com/profile_images/1777569006/image1327396628_normal.png",
"created_at": "Mon Feb 26 18:05:55 +0000 2007",
"location": "San Francisco, CA",
"follow_request_sent": false,
"profile_link_color": "547980",
"is_translator": false,
"id_str": "795649",
"default_profile": false,
"contributors_enabled": true,
"favourites_count": 3162,
"url": null,
"profile_image_url_https": "https://si0.twimg.com/profile_images/1777569006/image1327396628_normal.png",
[...]
}
En este artículo no nos detendremos en detalles secundarios como instalación del composer, establecimiento de permisos en el sistema de archivos o creación de la bbdd. Empezaremos desde el principio, creando nuestro proyecto desde cero, en la version 2.7 que es la más actual.
Vamos a echar un ojo a la extensión database de PHPunit, PHPUnit_Extensions_ Database_TestCase, una de las extensiones que posee para testear operaciones contra la bbdd.
Cuando usamos esta extensión añadimos dos metodos importantes, getconnection() y getDataSet(). Con el primero obtenemos un objeto conexión a la base de datos. Con el segundo obtenemos un subconjunto de datos y lo escribimos en nuestra base de datos. Este dataset puede estar basado en un archivo estatico o en queries.
En escenarios complejos los ficheros estaticos o fixtures, nos ayudarán a establecer un escenario sobre el cual probar nuestros métodos. En ocasiones cuando es necesario probar un método que efectúa una operación muy concreta, por ejemplo efectuar el balance contable de un mes de un cliente en el presente año, una opción es crear un fixture personalizado que creará el escenario necesario previo a la prueba.
Una cosa hay que tener claro. Los tests unitarios no son test de bases de datos, un test unitario testea código y comprueba que ha hecho lo que tenia que hacer. Veamos lo que tiene que hacer un test de base de datos:
1.- Poner la base de datos en un determinado estado controlado y acotado (eso es, con un fixture).
2.- Ejecutar el código que efectúa operaciones con la base de datos.
3.- Verificar que el estado actual y lo esperado son lo mismo.
El tercero de los puntos de SOLID es el principio de sustitucion de Liskov. Fue desarrollado por Barvara Liskov y Jeannette Marie Wing en la decada de los noventa. En su definición más formal tenemos que: si S es un subtipo de T, entonces los objetos de tipo T en un programa de computadora pueden ser sustituidos por objetos de tipo S (es decir, los objetos de tipo S pueden sustituir objetos de tipo T), sin alterar ninguna de las propiedades deseables de ese programa (la corrección, la tarea que realiza, etc.).
Esto traducido al ámbito de la orientación a objetos, nos dice que si a un método M le podemos pasar objetos t1 de la clase T, el método hace correctamente su función. Entonces si tenemos que La clase S hereda de T e instanciamos un objeto s1 de la clase S, entonces podríamos pasarle este objeto s1 al metodo M y todo funcionará sin ningun problema.
En el mundo de la orientacion a objetos el concepto de herencia o extension se puede traducir al lenguaje hablado como: "ES UN". Cuando decimos X es un Y, entonces podemos aplicar herencia entre nuestras dos entidades:
Lo que nos dice este principio es que "las entidades de software (clases o funciones…) deben estar abiertas para extenderse, pero cerradas para modificación". Esto no es mas que una planificacion correcta del flujo de vida de una entidad.
Acotando en la medida de lo posible el continuo remendado de dicha entidad dejando solo la posibilidad de actualizar o extender.
Nuestro objetivo es dejar la clase inalterada y dejar solo la puerta abierta a la posibilidad de añadir nuevo comportamiento. Para poder llevar a cabo esto es imprescindible tener un conocimiento de la aplicacion y de su alcance profundo, aunque esto no siempre es posible. Veamos un ejemplo sencillo que nos hará rapidamente violar el principio Abierto-Cerrado.
El principio de la única responsabilidad es tan sencillo como su nombre indica. Una clase solo debe tener una única función o cometido. A primera vista podría parecer sencillo y trivial pero en ocasiones no es así y es facil caer en la tentación: "ya que estoy aqui le meto esto también". Se acaba teniendo clases que hacen infinidad de cosas dificultando el mantenimiento y el testeo. Una clase con menos responsabilidades que otra tendra más garantías de perdurar en el tiempo, sin estar sujeta a reiteradas mejoras y actualizaciones. Supongamos una clase encargada de hacer una única tarea. Aplicar aqui reusabilidad de codigo será siempre más fácil que si heredamos una librería con miles de lineas y n funciones que habrá que repasar para poder integrar en nuestro código. El principio de la unica responsabilidad o SRP, por sus siglas en ingles establece que:
Solo debe haber un motivo para cambiar una clase, en el sentido de que solo debe tener una unica tarea.
A principios de 2000 el ingeniero americano Robert C Martin dió forma a los conceptos que hay detrás del acronimo SOLID. Estos 5 principios reunen las bases que todo programador de orientación a objetos debería tener presentes a la hora de desarrollar.
Inicial | Concepto |
---|---|
S |
|
O |
|
L |
|
I |
|
D |
|