Piratería: Una forma de destrucción.

Hoy voy a hablar de un tema que me preocupa pero lamentablemente es un mal que no desaparecerá: La piratería.

Ésta es la era digital, todo lo que estimula nuestras mentes se encuentra ya en formato digital: Los libros, la música, las películas, etc.

En décadas anteriores a los 90, una persona tenía generalmente 2 alternativas a la hora de escuchar música: O bien compraba el disco que quería escuchar luego de un proceso de selección, o bien grababa en cassettes discos que poseían sus amigos. La diferencia de calidad era sumamente notoria, lo mismo podía apreciarse con los libros fotocopiados y en menor forma con las películas en video-cassette, en todos los casos había un factor importante que potenciaba o bien la compra o bien copia de contenidos: la calidad.

Con el advenimiento de la era digital y las comunicaciones no sólo la calidad de las copias aumentó significativamente sino que también nuestra capacidad de compartir contenidos.

Ahora bien, lo que en un principio era una pérdida de utilidades extra para escritores, músicos, etc, con la evolución esa pérdida de utilidades se convierte día a día en una forma de destrucción y, si esto sigue así, en un futuro a los escritores de libros de todo tipo no les será rentable convertir en masivo el conocimiento, a los músicos no les será rentable producir música nueva y así, algunas áreas más golpeadas que otras se irá frenando cada vez más la producción de todo tipo de contenidos.

Las personas que hoy crecen y estimulan su intelecto descargando de la red los contenidos pirateados serán mañana afectados por la no-producción de los mismos.

En pocas palabras pirateando hoy, estamos destruyendo aquello que nos estimula y no progresará mañana. Terminaremos todos escuchando música vieja, leyendo libros con conocimientos anticuados, utilizando software de baja calidad y que por ser pirateado no se puede actualizar, etc.

Una frase que uno debe tener en cuenta a la hora de piratear contenidos es la siguiente: LA PIRATERÍA ES UN ROBO. ¿A quien estamos robando? A todas las personas involucradas en el proceso de elaboración de los contenidos.

¿Que se puede hacer?
Bajo el paradigma original la forma de soportar la creación de contenidos era comprar dichos contenidos en el soporte. Hoy en día dichos soportes resultan, en algunos casos, menos que convenientes, en pocas palabras, para muchos casos, la digitalización es necesaria, pero las personas se rehusan a comprar contenidos digitales que resultan "intangibles" y ni siquiera produce cargo de conciencia el hecho de piratearlos.
Es evidente que para la producción de contenidos, debe haber dinero involucrado pues quien produce contenidos también es una persona y necesita un sustento para su vida, sin contar que dicha producción es su trabajo.

Posiblemente una solución que deje contentas a muchas personas podría ser la puesta a disposición para descarga libre de contenidos y un sistema de donaciones mediante el cual, la gente que pueda hacerlo, le de soporte al proceso y el arte no muera.

Dicho esto, me despido del post y espero opiniones para el asunto.
Saludos y por favor, no pirateen en la medida de lo posible! no maten aquello que disfrutan!

Pruebas de Unidad: JUnit 4 y Netbeans IDE

Muchas veces en la incansable labor de desarrollo de software, nos vemos en la necesidad de probar lo que hemos hecho. La forma que primero se nos viene a la cabeza es correr la aplicación, cargar los datos, y ver que todo ande bien.
Eventualmente no tendremos la posibilidad de ejecutar la aplicación completa, o la ejecución de ésta es algo que consume mucho tiempo y es muy laborioso, sin contar que a veces dependemos de necesitar listo el trabajo de otras personas para probar nuestro código. Ahí es donde cobra sentido la automatización de las pruebas de unidad.

La herramienta propuesta por Netbeans IDE y que ciertamente es la más utilizada en el ambiente es jUnit. En este post presentaré las nociones básicas de uso de la versión 4 de jUnit, basado en Annotations.

Utilizar esta herramienta es realmente sencillo, utilizaré la siguiente clase (realmente trivial) como sujeto de pruebas:

public class Matematica {
public int dividir(int a, int b) {
return a / b;
}
}

Para comenzar, creo dentro de mi proyecto de netbeans, en test packages, mi clase que será la Suite de pruebas (o conjunto de pruebas seleccionadas). Cada prueba se realiza dentro de un método y este deberá estar anotado con @Test.

Nuestra primera clase de prueba es esta:

import org.junit.Test;
import org.junit.Assert;

public class PruebaMate {

@Test
public void pruebaCero() {
int valor = new Matematica().dividir(4, 2);
Assert.assertEquals(2, valor);
}

}

A esta clase le iremos agregando cosas a medida que vayamos avanzando.
Para comenzar la prueba en netbeans, click derecho a la clase de prueba dentro del explorador de proyectos y le damos la opción "Run".

Presentando la siguiente salida:

Testsuite: PruebaMate
Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0,089 sec

test:
BUILD SUCCESSFUL (total time: 1 second)

Esto nos dice que la prueba se ejecutó, y no sólo eso sino que se realizó correctamente y el tiempo que tardó.

Ahora agregaremos el siguiente método para probar como se comporta con la división por 0:

@Test
public void pruebaUno() {
new Matematica().dividir(4, 0);
}

Y al correrlo obtenemos la siguiente salida:

Testsuite: PruebaMate
Tests run: 2, Failures: 0, Errors: 1, Time elapsed: 0,061 sec

Testcase: pruebaUno(PruebaMate): Caused an ERROR
/ by zero
java.lang.ArithmeticException: / by zero
at Matematica.dividir(Matematica.java:3)
at PruebaMate.pruebaUno(PruebaMate.java:14)


Test PruebaMate FAILED
test:
BUILD SUCCESSFUL (total time: 0 seconds)

Ahora vemos que en realidad la segunda prueba no debió haber fallado ya que en java la división por cero causa esa ArithmeticException. Para decirle a jUnit que realmente esa excepción no es mala sino que debería considerarse como resultado exitoso de la prueba, lo hacemos a través de el annotation @Test, el método quedará de la siguiente forma:

@Test(expected=ArithmeticException.class)
public void pruebaUno() {
new Matematica().dividir(4, 0);
}

Y al ejecutar la prueba vemos lo siguiente:

Testsuite: PruebaMate
Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0,049 sec

test:
BUILD SUCCESSFUL (total time: 0 seconds)

Nota: En caso que nuestra excepción necesitara ser declarada, agregamos la cláusula throws a nuestro método de prueba.

Ahora posiblemente antes de cada prueba necesitemos realizar un setup del entorno para que se adapte al entorno de producción, esto lo realizaremos con métodos anotados con @After y @Before, por ejemplo realizaremos la instanciación de la clase matemática antes de cada prueba y sugeriremos la recolección de basura después. La clase de pruebas modificada se ve de la siguiente forma:

import org.junit.After;
import org.junit.Test;
import org.junit.Assert;
import org.junit.Before;

public class PruebaMate {

@Test
public void pruebaCero() {
int valor = m.dividir(4, 2);
Assert.assertEquals(2, valor);
}

@Test(expected=ArithmeticException.class)
public void pruebaUno() {
m.dividir(4, 0);
}

private Matematica m;

@Before
public void iniciar() {
System.out.println("Inicio la prueba");
m = new Matematica();
}

@After
public void terminar() {
System.out.println("Termino la prueba");
m = null;
System.gc();
}
}


Y al ejecutar la prueba vemos el resultado:


Testsuite: PruebaMate
Inicio la prueba
Termino la prueba
Inicio la prueba
Termino la prueba
Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0,1 sec

------------- Standard Output ---------------
Inicio la prueba
Termino la prueba
Inicio la prueba
Termino la prueba
------------- ---------------- ---------------
test:
BUILD SUCCESSFUL (total time: 0 seconds)


Ahora, instanciar la misma clase una y otra vez por cada prueba no es barato, como se puede observar en los tiempos de ejecución. Si queremos realizar algo antes de todo y luego algo después de todo utilizamos los annotations @AfterClass y @BeforeClass, modificamos la clase de pruebas de la siguiente forma:

private static Matematica m;

@BeforeClass
public static void iniciar() {
System.out.println("Inicio la prueba");
m = new Matematica();
}

@AfterClass
public static void terminar() {
System.out.println("Termino la prueba");
m = null;
System.gc();
}

Cambiando a static ya que las anotaciones requieren que los métodos sean static. Y los resultados de la ejecución son los siguientes:

Testsuite: PruebaMate
Inicio la prueba
Termino la prueba
Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0,073 sec

------------- Standard Output ---------------
Inicio la prueba
Termino la prueba
------------- ---------------- ---------------
test:
BUILD SUCCESSFUL (total time: 0 seconds)


Con lo que terminamos este tutorial introductorio para realizar pruebas de unidad, las cuales nos ahorran mucho tiempo de introducción de datos y a medida que pasa el tiempo y las pruebas se acumulan nos sirven para verificar que los cambios introducidos en el mantenimiento de las aplicaciones, no tengan efectos adversos sobre la funcionalidad existente.

Espero que les sirva. Saludos!

Modem 3g Claro en Linux

Hace un tiempo experimenté con sorpresa que al enchufar el modem claro 3g huawei en mi notebook con ArchLinux, networkmanager me lo reconoció sin problemas.
Al tratar de conectarme me solicitó los siguientes datos:

• Nro de teléfono: *99#
  
• usuario: ctigprs
  
• clave: ctigprs
  
• APN: internet.ctimovil.com.ar

Bien, con esto logré conectarme pero internet no andaba ni para atrás ni para adelante.

Al mirar mi archivo /etc/resolv.conf vi lo siguiente:

nameserver 4.3.2.1
nameserver 4.3.2.1

#(también podría haber sido 1.2.3.4, no lo recuerdo.)

Esto evidentemente está mal por lo cual luego de un poco de investigación descubrí que los dns eran los siguientes:

#/etc/resolv.conf

nameserver 170.51.255.100
nameserver 170.51.255.167

Bien, en un principio pensé que eso resolvería mi problema de conexión pero no. Al escribir el comando 'route' noté que el dhcp tampoco me entregó bien la puerta de enlace. Inspeccionando un poco vi también que si bien tenía una dirección ip (proporcionada por la negociación ppp), la máscara de red era 255.255.255.255. Teniendo esa máscara resulta obvio que no podría conectarme a ninguna pc en esa red que no sea la mía. Inspeccionando la configuración que entregaba el mismo módem en windows vi que la puerta de enlace en efecto era la misma ip que nos entregó la necociación ppp.

Por lo cual, con el comando route, y suponiendo que mi ip es: 186.122.192.127

# route add default gw 186.122.192.127

Una vez corregido esto, pude navegar perfectamente con el modemcito.

Les dejo acá un snapshot de como se vería la configuración parael modem en knetworkmanager.



Saludos!

Yo tocando.

Hoy se me dio por filmarme, aunque la camara me pone muy nervioso. Jaja.



Espero críticas y comentarios.
Saludos!