Securizando un directorio de Apache 2.4 con user/password en un fichero. Ubuntu 14.04 Servr

Es algo realmente típico y sencillo. Vamos con los pasos fundamentales. Asumimos que tenemos el Apache 2.4 ya montado corriendo una aplicación en Ubuntu 2.4.

Creamos el fichero de Passwords (si no está creado).

  1. Instalamos la utilidad para crearlo:
    sudo apt-get install apache2-utils
  2. Creamos un usuario/password para el fichero deseado. Si no existe el fichero lo genera con el parámetro -c. Si queremos añadir usuarios ya exsitentes, quitamos el -c
    sudo htpasswd -c /etc/apache2/.htpasswd antonio
  3. Comprobamos que el fichero se ha creado y que los password están cifrados
    cat /etc/apache2/.htpasswed

Indicamos que se utilice el fichero.

  1. Localizamos el fichero de configuración del site que estamos utilizando
    cd /etc/apache2/sites-available/
  2. Localizamos el fichero de configuración del site que estamos utilizando. Suele ser el que se indica a continuación.
    vim 000-default.conf
  3. Añadimos esta configuración para restringir el directorio /var/www/administrator
    <Directory "/var/www/administrator">
     AuthType Basic
     AuthName "Restricted Content"
     AuthUserFile /etc/apache2/.htpasswd
     Require valid-user
     </Directory>
  4. Reiniciamos el Servidor para reflejar los cambios.
    sudo /etc/init.d/apache2 restart

Accedemos a la dirección web que necesitamos y vemos que nos pide el usuario y password, y que funciona indicando uno de los proporcionados en el fichero.

Esto debería ser todo ^_^

Big Data Spain 2015

Este año 2015, gracias a Autentia, he podido asistir a las conferencias Big Data Spain 2015 sobre los últimos avances en Big Data. Aquí os dejo el storify hecho a base de tweets que tuve la oportunidad de publicar durante el evento.

https://storify.com/4lberto/big-data-spain-2015

También hemos publicado 3 entradas en la página adictosAlTrabajo.com de Autentia con las crónicas y el stack de tecnologías.

Refactorizando métodos no-deterministas para poder hacer Test Unitarios

En una nueva colaboración con el portal AdictosAlTrabajo.com, hago un repaso de algunas técnicas que se pueden utilizar para refactorizar métodos no-deterministas (aleatorios) y así poder hacer Test Unitarios.

Aquí está el enlace: http://www.adictosaltrabajo.com/tutoriales/refactorizando-metodos-no-deterministas-para-poder-hacer-test-unitarios/

Disfrutad!

Subir un proyecto existente a GitHub

Si tenemos un proyecto ya hecho en nuestro ordenador podemos subirlo a Github muy rápidamente:

1. Ir al directorio base del proyecto y ejectuar: git init

2. Ir a http://github.com y logarnos con nuestro usuario. Crear un nuevo proyecto.

3. Ir al directorio base del proyecto y configurar la URL del nuevo proyecto de GitHub: git remote add origin https://github.com/4lberto/atascator.git

4. Proceder normalmente:

  • git pull origin master (para bajar el README.md si lo hemos hecho).
  • git add .
  • git commit -m “primer commit”
  • git push origin master
  • etc…

Bytecode: ¿Sabes lo que realmente programas en Java?

En una nueva colaboración con el portal http://www.adictosaltrabajo.com/ escribo sobre la importancia de conocer el Bytecode que se genera cuando se compila en Java, y sobre cómo hace la máquina virtual de Java para convertirlo a código máquina real.

Puedes encontrarlo aquí: http://www.adictosaltrabajo.com/tutoriales/tutoriales.php?pagina=ByteCode

Imprimiendo documentos Office y PDF existentes en una red Windows desde Java con Batch & Print

Imprimir desde Java no es una tarea nada sencilla, sobre todo para los documentos Office y PDF en una red Windows.

En un post en el portal www.adictosaltrabajo.com comento cómo se puede resolver esta problemática a través de diferentes enfoques, tanto dentro de Java como usando un producto externo llamado Batch & Print.

http://www.adictosaltrabajo.com/tutoriales/tutoriales.php?pagina=impresionJava

Experimenta con tu código en Eclipse utilizando Scrapbooks

Eclipse dispone de una funcionalidad llamada Scrapbook para poder hacer pruebas de tu código Java antes de implementarlo en la clase final.

Puedes acceder a este post del portal www.adictosaltrabajo.com en el que colaboro: http://www.adictosaltrabajo.com/tutoriales/tutoriales.php?pagina=Scrapbook

PS: Incluso sale mencionado en GenbetaDev 🙂 http://www.genbetadev.com/actualidad/mirar-a-gente-programando-prejuicios-refactoring-codigo-y-felicidad-pull-request-26

PrimeFaces (JSF2). Cómo detectar el fin de carga de la página con JavaScript

Primefaces  es una librería que implementa JSF2, de modo que facilita la creación de aplicaciones Web en un entorno J2EE a través del uso de componentes prefabricados como menús, botones, tablas de datos, formularios, etcétera. Puedes encontrar demostraciones de su potencial y un catálogo de sus componentes en este enlace: http://www.primefaces.org/showcase/

Aunque se use Primefaces, el resultado que llega al navegador siempre es el mismo: un conjunto de etiquetas HTML junto con complejas implementaciones en JavaScript que se generan automáticamente a partir del código Java y de componentes en XHTML. Como todo sistema que abstrae al programador de los niveles inferiores, siempre es complicado realizar algunas operaciones específicas que se salen de lo establecido para la tecnología.

Tal es el caso de la detección de cuándo se ha terminado de cargar la página y el usuario tiene toda la información para operar. Habría que distinguir dos fases de forma genérica:

  • Carga de la estructura HTML de la página
  • Carga de las llamadas asíncronas (AJAX) para la obtención de datos.

En muchas ocasiones JSF2 (y por ende Primefaces) utilizan AJAX para obtener los datos del servidor, lo que implica que la página puede haber cargado su estructura y scripts, pero éstos continúan con su ejecución. El resultado es que el usuario no puede utilizar la página hasta un poco después de que el navegador le haya notificado que ha acabado: faltan tablas por completar, combos, datos dinámicos, etcétera.

Sería bueno por lo tanto contar con un mecanismo que nos permitiese realizar alguna acción cuando se ha terminado esa carga de datos. Se puede usar en algunas ocasiones cuando los que nos ofrece PrimeFaces no es suficiente: por ejemplo bloquear la pantalla con un fondo e icono de carga hasta que no esté plenamente operativa en la primera carga.

Como PrimeFaces utiliza jQuery para operar, simplemente aprovecharemos la posibilidad que nos brinda esta librería de Javascript: se enlazan un document.ready dentro de otro, de modo que el segundo se ejecutará cuando haya acabado el primero, que es el que contiene todas las operaciones de PrimeFaces

$(document).ready(function(){
    $(document).ready(function(){
        //Código Javascript que queramos ejecutar después de Primefaces
    });
});

Diseño dirigido por testing continuo (CTDD) en Eclipse con Infinitest

Si usas habitualmente del desarrollo guiado por test (Test Driven Development) seguro que te has hartado de ejecutar test y test hasta llegar a ver la señal de color verde que indica que los test han pasado.

Si no has probado nunca el TDD, te lo recomiendo. Básicamente (y de forma seguramente imprecisa, pero por motivos didácticos…) se resumiría en:

  1. Se crea un test que debería cumplir el código que voy a programar.
  2. Se ejecuta el test y se falla, obteniendo una señal de color rojo (como un semáforo).
  3. Se programa el código mínimo que hace que el test se cumpla.
    1. Se ejecuta el test y se puede obtener una señala roja de fallo, por lo que hay que modificar el código.
    2. Se ejecuta el test y se obtiene una señal verde que indica que el test ha pasado.
  4. Se genera otra vez otro test con más requisitos que debe cumplir.

La ejecución de los test se realiza en el IDE o a través de herramientas como Maven o un sistema de integración continua. Si lo hacemos en nuestro IDE, puede ser algo tedioso ya que tenemos que ejecutarlo manualmente cada vez que queramos probar si nuestro código hace cumplir el test que hemos creado.

  1. Programamos el código que se supone que pasa el test unitario.
  2. Localizamos la clase del test (unitario) que corresponde al fragmento de código que hemos programado (a veces se nos pierde entre un tumulto de pestañas).
  3. Ejecutamos el test.
  4. Vemos el resultado.
    1. Y si ha fallado, vuelta a empezar.

Aunque en los ID como Eclipse es fácil con las teclas cmd+alt+R+T (quizá no tanto jeje), podemos acabar algo cansados.

Para evitar esto podemos utilizar un plugin que nos permite realizar testing continuo (Continuous Test Driven Development – CTTD) esto es, que cada vez que modificamos un fichero de código, los test asociados a él se ejecutan en segundo plano de modo automático y sin intervención del desarrollador), obteniendo el resultado de los mismos en un lateral de la pantalla.

Aunque automatizar la ejecución continua de test puede ser algo muy básico, es de gran ayuda. Sintetizaría sus ventajas en los siguientes puntos:

  • Evita perder tiempo porque no tenemos que localizar el test que le incumbe al código modificado, o no tenemos que correr todos los test (porque no queremos localizar el test).
  • Quizá nos pueda evitar dar alguna vuelta de más al código al tener de forma más constante el resultado del test.
  • Y lo más importante: Ayuda a enfocarse todavía más en el paradigma TDD al proveer un feedback continuo de nuestras acciones.

Si buscamos herramientas CTTD para Eclipse, que es el IDE que suelo utilizar, aparecen unas cuantas. He probado una que parecía sencilla. Se llama Infinitest. Vamos a ver cómo se instala y se utiliza. Es muy fácil.

Infinitest

Screenshot from 2014-11-22 10:39:41

Infinitest está disponible para Eclipse e IntelliJ IDEA en forma de plugin que se integra perfectamente con el navegador. Su modo de funcionamiento se puede resumir en estos pasos:

  1. Primera ejecución: pasa todos los test que hay en el proyecto para conocer qué código está cubierto por cada test. De este modo, cuando salvemos un fichero, sabrá qué test tiene que ejecutar, evitando tener que correr todos otra vez.
  2. Siguientes ejecuciones: cuando salvemos un fichero de código, comprueba qué test se le aplican y los ejecuta en segundo plano, informando del resultado de dos modos (en Eclipse):
    1. Mediante un indicador en la zona inferior izquierda con el típico semáforo verde – rojo de los test.
    2. Mediante la pestaña de errores del proyecto, donde tiene su apartado específico.
    3. Mediante una señal de error en el código del test que ha fallado, donde devuelve el error de JUnit (fallo de Assert…).

Los pasos par instalarlo en Eclipse son muy sencillos, son los siguientes (perdón por los colores del Eclipse Luna con el tema Dark ^_^):

1. Vamos al Eclipse Marketplace (Menú Help > Eclipse Market Place…).

2. En la caja Find escribimos “Infinitest” y esperamos al resultado.

Screenshot from 2014-11-22 09:41:28

3. Aceptamos condiciones de instalación (y advertencias de contenido no firmado ^_^)

4. Reiniciamos el IDE.

Cuando iniciamos de nuevo Eclipse y si no se ha ejecutado nunca, aparecerá un nuevo control en forma de barra en la zona inferior izquierda de la pantalla, que indica que Infinitest está esperando acciones.

Screenshot from 2014-11-22 09:44:27

He creado un proyecto muy sencillo para probar su funcionamiento. Sea el siguiente test que requiere un contador que cuente palabras y devuelva el valor de tipo int “6” al ejecutarse:

test

Si seguimos el paradigma TDD, debemos escribir el código mínimo que supere el test. Podría ser este.

test

 

Sí, si te lo estás preguntando, solamente devuelve un 6 sin hacer operaciones porque es lo que el test ha pedido. Se trata de cumplir el test con el código mínimo. Si esperabas la funcionalidad de que contase el número de palabras, se debería haber especificado en el test poniendo más casos.

Volviendo al CTTD con Infinitest. En el momento que salvamos el fichero de código que pretendo cumplir el test, Infinitest ejecuta todos los test del proyecto para detectar las dependencias código-test. Ahora cada vez que salvemos ejecutará los necesarios. El resultado de la ejecución se muestra en la zona inferior izquierda:

Screenshot from 2014-11-22 10:17:53

Y como nuestro código es adecuado, ¡tenemos una bandera verde! Podemos añadir otro test para llegar donde queremos.

test3

Nada más salvar el fichero del test (un cmd+s o ctrl+s), podemos ver que aparece una señal de error en Eclipse (la bombilla con una equis en la línea 13). El indicador de Infinitest también los avisa.

test4

Si vamos a la pestaña “Problems” podemos ver las causas:

TEST5

Obviamente el problema está en que nuestro código simplemente devuelve un número 6 y no cumple el segundo test. Modificamos el código de nuestra clase para que cuente las palabras del texto pasado por parámetro. Se me ha ocurrido hacer un split y contar el vector resultante:

Test6

Y nada más salvar el código de nuestra clase, el test correspondiente se ha ejecutado en segundo plano. Los fallos del test desaparece también.

Screenshot from 2014-11-22 10:35:03

Como habéis podido ver, en este proceso tendría que haber ejecutado el test unitario al menos 4 veces si siempre hubiera acertado con la solución a los test a la primera. Asi que he ahorrado un tiempo y distracciones, y he podido concentrarme en escribir el código adecuado.

Por supuesto, el hecho de disponer de una herramienta para hacer CTTD no sustituye ninguna de las otras partes del TDD, es simplemente una ayuda más para acelerar el proceso. Debemos seguir ejecutando todos los test de forma periódica y debemos seguir utilizando los sistema de integración y generar las builds como siempre

Seguro que cuando lo pruebes será un clásico en tu IDE (o al menos otra herramienta que permita hacer CTTD).