A la hora de ir haciendo las muy útiles pruebas unitarias para ir verificando que el código funciona correctamente, existen múltiples posibilidades para tratar este tema.

Por un lado están las pruebas de caja negra (ejecución de tests, digamos) y por el otro, las de caja blanca (cubrir todas las líneas de código implementadas).

JUnit

Con esta herramienta realizamos las pruebas. Tan simple como seguir el manual de la propia página o cookbok.

ECLEmma

Gracias al plugin para Eclipse, se consigue averiguar la cobertura de código que se realiza con los tests. De esta forma, se consiguen unas pruebas más completas.

Creando el script en Ant

Al añadir a Ant las líneas adecuadas para la ejecución de pruebas de manera automática, se ha optado por usar Cobertura. De esta manera, se automatiza el proceso de cobertura fácilmente.

El proceso consiste en añadir en Ant las librerías de cobertura y después, especificar varias opciones. Todo este proceso se explica adecuadamente, a mi parecer, en la propia página de Cobertura.

En nuestro caso, esta parte quedaría así:

<path id="cobertura.classpath">
   <fileset dir="${cobertura.dir}">
   <include name="cobertura.jar" />
   <include name="lib/**/*.jar" />
   </fileset>
 </path>

Luego entre las opciones a especificar:

<!-- =================================

	target: instrument

 ================================= -->

	<target name="instrument"

		description="Crea las clases de instrumentación para generar la cobertura"

		depends="init.instrument">

		

		<!-- Se eliminan los ficheros de ejecuciones anteriores -->

		<delete file="cobertura.ser" />

		<delete dir="${build.instrumented.dir}" />

		

		<cobertura-instrument todir="${build.instrumented.dir}">

	    	<fileset dir="${build.dir}/classes">

	        	<include name="**/*.class" />

	    	    <exclude name="**/*Test.class" />

		    </fileset>

		</cobertura-instrument>

	</target>

	

<!-- =================================

	target: test

 ================================= -->

	<target name="test" depends="init,compile,instrument" description="Ejecuta las pruebas de cobertura. Para ello es necesario

		tener ejecutando el motor de MySQL y Matlab.">

		<junit fork="yes" dir="${basedir}" failureProperty="test.failed">

	    	<classpath location="${build.instrumented.dir}"/>

	    	<classpath location="${build.classes.dir}"/>

			<classpath location="${build.dir}"/>

			<classpath refid="sql.classpath" />

			

			<formatter type="xml"/>

			<classpath refid="cobertura.classpath" />

			

			<formatter type="xml" />

			<test name="${testcase}" todir="${report.junit.dir}" if="testcase"/>

		

			<batchtest todir="${junit.xml.dir}" unless="testcase">

				<fileset dir="${test.dir}">

					<include name="**/*.java"/>

				</fileset>

			</batchtest>

		</junit>

		

		<junitreport todir="${junit.xml.dir}">

			<fileset dir="${junit.xml.dir}">

				<include name="TEST-*.xml"/>

			</fileset>

			<report format="frames" todir="${junit.html.dir}" />

		</junitreport>

	</target>

	

<!-- =================================

	target: coverage-check

 ================================= -->

	<target name="coverage-check" depends="" description="Comprueba que las pruebas de cobertura están en un intervalo especificado">

			<cobertura-check branchrate="35" totallinerate="100" />

	</target>

	

<!-- =================================

	target: coverage-report

 ================================= -->

	<target name="coverage-report" depends="test" description="Crea un informe html con la cobertura de las pruebas">

		<cobertura-report destdir="${cobertura.html.dir}">

		   <fileset dir="${src.dir}">

		       <include name="**/*.java" />

		       <exclude name="**/*Stub.java" />

		   </fileset>

		</cobertura-report>

	</target>

	

<!-- =================================

	target: coverage-report-xml

 ================================= -->

	<target name="coverage-report-xml" depends="coverage-report" description="Crea un informe xml con la cobertura de las pruebas">

	    <cobertura-report format="xml" srcdir="${src.dir}" destdir="${cobertura.xml.dir}"/>

	</target>

Y tras unos días de descanso y otros tantos sin actualizar el blog, volvemos al trabajo con unas ganas tremendas (nótese la ironía).

Tras el post anterior sobre la instalación de esos “elementos”, decidimos instalar un wiki, ya que se ajustaba perfectamente a lo que nosotros queríamos.

Variedad de wikis hay, ya sean en PHP, en Java, y en todo lo imaginable, pero uno que nos funcionara de manera correcta con PHP (lo que queríamos) pocos. Tras probar a instalar MediaWiki probando varias versiones de quercus y del mismo wiki, y no obtener éxito (lo cual seguimos sin entender, ya que en los lugares donde hemos mirado lo instalan sin problemas :S), encontramos WikkaWiki, el cual es muy ligero y para lo que necesitamos, y nos basta.

Su instalación es sencillísima y se acopla con Quercus y MySQL perfectamente. Crea un número muy reducido de tablas, lo cual nos ahorra bastante trabajo y el proceso de creación de artículos es igual al de todos los wikis.

La instalación se realiza descomprimiendo el archivo descargado en la carpeta docroot del dominio de GlassFish y siguiendo los pasos de la instalación que aparecen en pantalla. Para más información me remito a la documentación de Wikka.

Y este post no requiere más esfuerzo (porque yo lo valgo).

Todavía dudo de si esto nos va a servir para algo, pero ya que lo hemos estado investigando, pongo cómo hemos conseguido hacer funcionar este batiburrillo :D

En un principio teníamos la idea de montar un foro local con algunos datos para luego usarlos en la creación del mapa de imágenes. Y eso es lo que hicimos.

Tenemos configurado ya GlassFish, por tanto, ahora hay que hacerse con PHP y MySQL, los requisitos mínimos necesarios para montar un foro en un servidor local.

PHP en GlassFish

Para poder ejecutar PHP en GlassFish, se puede usar Quercus, que recomiendan por todos los lados al poner esas dos palabras en nuestro querido Google. También he encontrado otra llamada Java/PHP Bridge, que también puede ser una alternativa interesante, pero nos decidimos por la recomendada.

De la página principal de Quercus, se puede obtener el .war necesario para su funcionamiento en GlassFish. Tras su descarga, se coloca en la carpeta autodeploy del dominio donde se quiere tener PHP, esto es, por ejemplo, en la carpeta domain, se encuentra la carpeta domain1 y en ésta, la de autodeploy. Si se mete aquí, entonces se podrá ejecutar PHP en este dominio únicamente. Aunque ésto no es sólo lo que hay que hacer para que funcione. Como he comentado, si se quiere en un dominio concreto, entonces se modifica el web.xml sustituyendo su contenido por esto:

<?xml version=”1.0″ encoding=”UTF-8″?>
<web-app xmlns=”http://java.sun.com/xml/ns/javaee”
  xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”
  xsi:schemaLocation=”http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd”
  version=”2.5″> 
  <description>Caucho Technology’s PHP Implementation, Running on GlassFish Java EE 5</description> 
  <servlet>
    <servlet-name>Quercus Servlet</servlet-name>
    <servlet-class>com.caucho.quercus.servlet.QuercusServlet</servlet-class>
  </servlet> 
  <servlet-mapping>
    <servlet-name>Quercus Servlet</servlet-name>
    <url-pattern>*.php</url-pattern>
  </servlet-mapping> 
  <welcome-file-list>
    <welcome-file>index.php</welcome-file>
  </welcome-file-list>
</web-app>

<?xml version=”1.0″ encoding=”UTF-8″?>

<web-app xmlns=”http://java.sun.com/xml/ns/javaee”

  xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”

  xsi:schemaLocation=”http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd”

  version=”2.5″> 

  <description>Caucho Technology’s PHP Implementation, Running on GlassFish Java EE 5</description> 

  <servlet>

    <servlet-name>Quercus Servlet</servlet-name>

    <servlet-class>com.caucho.quercus.servlet.QuercusServlet</servlet-class>

  </servlet> 

  <servlet-mapping>

    <servlet-name>Quercus Servlet</servlet-name>

    <url-pattern>*.php</url-pattern>

  </servlet-mapping> 

  <welcome-file-list>

    <welcome-file>index.php</welcome-file>

  </welcome-file-list>

</web-app>

 

Pero si se quiere PHP en general, en todo el servidor GlassFish, entonces hay que copiar las librerías contenidas en la carpeta lib del .war de Quercus y luego modificar el archivo default-web.xml situado en la carpeta config del dominio añadiendo las líneas siguientes:

<servlet>

<servlet-name>Quercus Servlet</servlet-name>

<servlet-class>com.caucho.quercus.servlet.QuercusServlet</servlet-class>

<init-param>

<param-name>ini-file</param-name>

<param-value>WEB-INF/php.ini</param-value>

</init-param>

</servlet>

<servlet-mapping>

<servlet-name>Quercus Servlet</servlet-name>

<url-pattern>*.php</url-pattern>

</servlet-mapping>

 

Se haga lo que se haga, se puede hacer un proyecto en Eclipse con un “hola mundo” en PHP y comprobar su funcionamiento.

MySQL

Para instalarlo se puede optar por descargar un paquete binario (.exe) o, como hemos hecho nosotros, un comprimido (.zip). La ventaja del comprimido frente al paquete ya la comenté en otro post y por eso segimos usando este camino, a no ser que no haya otra manera. Dicho esto, descargamos el comprimido de la página de MySQL (without installer) y también, ya que estamos, el GUI Tool, que es la interfaz gráfica para acceder más cómodamente a la Base de Datos.

Descomprimidos los dos, instalación completada. Ahora queda cómo arrancar la Base de Datos. Y eso es situándose mediante línea de comandos en la carpeta bin donde está descomprimido el programa y escribir: mysqld. Así de simple se inicia MySQL. Para pararlo requiere de una línea más larga: mysqladmin -u root shutdown. Luego ya es cuestión de cada uno hacerse un bat para manejarse más comodamente :P

Para arrancar la interfaz, en la carpeta de la GUI Tool descomprimida se encuentra MySQLAdministrator para iniciarla. Se entra como root sin contraseña y, aunque aparezca un mensaje de error debido a que hay que crear un fichero de configuración, pero en nuestro caso no lo hemos hecho y, de momento, no nos hace falta. A partir de aquí ya es cada uno el que configura su Base de Datos a su gusto.

¿Y ahora cómo creo el foro?

Tipos de foros para crear hay muchos y variados. Hemos escogido phpBB, aunque también eran una opción asequible  myBB, por ejemplo. Para crearlo basta con situarse en la carpeta docroot y descomprimir el archivo descargado. La instalación del foro está explicada en su respectiva página. Hay que tener mySQL rulando, por supuesto ;)

Y eso es… eso es… eso es todo, amigos :P

Fuentes: Variadas por la web, en especial, para el tema de PHP: http://blogs.sun.com/arungupta/entry/php_in_glassfish_using_caucho

Sí!! Al fin conseguimos lo que hemos estado trabajando durante todo este tiempo, y es la parte visual, lo que podría considerarse lo más importante y estamos muy orgullosos de haberlo conseguido, aunque no quede de una forma perfecta.

Para celebrarlo, unas capturillas por aquí y por allá, de lo que se muestra en el navegador, aunque lo mejor es verlo funcionar por uno mismo :P

Si se pulsa en una etiqueta se accede al nivel inferior y se ve con más “detalle”. Todo el código HTML lo hemos creado desde Java, cogiendo los datos que obteníamos en Matlab y creando código HTML en Java siguiendo la estructura necesaria para hacer un mapa de imágenes, la cual es la siguiente (en nuestro caso, de forma rectangular):

<HTML>
<HEAD><TITLE>WebSOM</TITLE></HEAD>
<BODY>
<map name=”chicken”>
<area shape=”RECT” coords=”0,0,40,38″ href=”C:\Documents and Settings\Javi\Mis documentos\Eclipse Workspace\Servidor\etiqueta2_chicken.html”>
<area shape=”RECT” coords=”0,266,40,304″ href=”C:\Documents and Settings\Javi\Mis documentos\Eclipse Workspace\Servidor\etiqueta2_flamingo.html”>
<area shape=”RECT” coords=”40,152,80,190″ href=”C:\Documents and Settings\Javi\Mis documentos\Eclipse Workspace\Servidor\etiqueta2_lark.html”>
</map>
<img src=”C:\Archivos de programa\MATLAB\R2008a\work\somtoolbox\mapa1_chicken.png” width=”80″ height=”311″ alt=”chicken” border=”0″ usemap=”#chicken”>
</BODY>
</HTML>

<HTML>

<HEAD><TITLE>WebSOM</TITLE></HEAD>

<BODY>

<map name=”chicken”>

<area shape=”RECT” coords=”0,0,40,38″ href=”html\etiqueta2_chicken.html”>

<area shape=”RECT” coords=”0,266,40,304″ href=”html\etiqueta2_flamingo.html”>

<area shape=”RECT” coords=”40,152,80,190″ href=”html\etiqueta2_lark.html”>

</map>

<img src=”img\mapa1_chicken.png” width=”80″ height=”311″ alt=”chicken” border=”0″ usemap=”#chicken”>

</BODY>

</HTML>

 

Los enlaces finales no llevan a ningún lado, y esto depende de los datos de entrada que se utilicen. Esta parte se implementará más tarde.

Hecho esto, ahora toca ponerse con el otro tema importante del proyecto: los datos de entrada. En un principio tenemos pensado coger un foro para obtener un mapa de imágenes que refleje varios niveles agrupados por categorías. Veremos a ver qué conseguimos y… para cuándo :roll:

Buf, demasiado tiempo sin poner nada, pero que no sea porque hemos estado haciendo el vago :)  En fin, espero añadir en pocos días algo en lo que hemos estado trabajando con la ayuda de SOMToolbox.

Hoy toca hablar del control de versiones utilizado para nuestro proyecto. ¿Qué es un control de versiones? Lo voy a explicar de forma muy muy simple, o eso espero, ya que para esto ya hemos tenido una asignatura tratando este y otros temas:

Inicialmente creas un fichero con código que funciona bastante bien haciendo lo estipulado, y lo guardas con el nombre fichero.java (por ejemplo). Más tarde ves que necesitas borrar algo para depurarlo, pero como el anterior te puede servir en un futuro, a este nuevo lo llamas ficherobueno.java. Otro día añades una nueva modificación y, para no quedarte sin lo anterior, lo llamas ficheromásbueno.java. Y así continuamente. ¿Qué consigues? Que llegue un día en el que quieras ver la versión que funcionaba con una característica específica y te encuentres con un montón de ficheros de los cuales no sabes ni cuál es el inicial.

Y por eso existe el control de versiones, facilitan mucho esta tarea para un programador (y varios, sobre todo). Existen programas de pago o uso libre, que incluso se integran con los entornos de desarrollo preferidos para cada usuario. Varios programas de este tipo se pueden encontrar en: http://en.wikipedia.org/wiki/List_of_revision_control_software

En nuestro caso escogimos Plastic SCM. ¿Por qué? Pues principalmente porque han instalado en el servidor de la Universidad una copia y esto nos facilita bastante las cosas a la hora de usarlo (no tener que mantener nosotros un servidor en alguno de nuestros ordenadores) y, también, porque uno de los creadores ha sido nuestro profesor (es una razón de peso :P ). El programa contiene plugins para integrarlo con Eclipse, Visual Studio y JDeveloper, para proteger/desproteger tus datos en el mismo entorno.

Así que, poco a poco vamos avanzando con la aplicación sin temor a perder datos. Y ahora más, ya que gracias a una clase magistral hemos podido refrescar varios de los conceptos (rama, merge, etiquetas,…) importantes a la hora de usar el programa.

 

Y la traca final… un poco de marketing para el producto (de nada, Pablo) :P

Se puede descargar una versión de prueba de Plastic SCM en http://www.codicesoftware.com/app01/opdownloads2.aspx (requiere registro). Además, se puede pedir una licencia gratuita si eres estudiante y lo necesitas para realizar un proyecto, así que no hay excusa para no probarlo, al menos.

Más información, con explicación de todas sus características y ejemplos: http://www.plasticscm.com/spproducts.aspx

Se trata de la herramienta que se está utilizando con Matlab para obtener como resultado el preciado WEBSOM, aunque a nuestra manera.

Esperamos obtener algún resultado visible pronto, ya que poco a poco se va conociendo más a fondo todas las funcionalidades que ofrece.

Este toolbox está desarrollado por personas de la Universidad de Finlandia, entre ellos el respetado Teuvo Kohonen, el creador de la SOM.

Pero… ¿qué es la SOM?

SOM (Self-Organizing Map)

No se trata de algo fácil de explicar para alguien que no ha oido hablar nunca de las neuronas artificiales, pero intentaré concretarlo:

Una neurona artificial emula a una neurona biológica (sí, de esas de las que tenemos cientos de miles), por tanto, de lo que se trata es que esa neurona “aprenda” a lo largo de un tiempo llamado período de aprendizaje.

Para dar una sencilla explicación de lo que es un SOM y el por qué es un método apropiado para ordenar y organizar:

Consideremos un sistema de procesamiento de información, como puede ser el cerebro, el cual debe aprender a llevar a cabo diversas tareas todas ellas de manera correcta. Asumamos que el sistema puede asignar diferentes tareas a subsistemas que son capaces de aprender a realizarlas. Cada nueva tarea es asignada a la unidad que mejor puede completarla. Las unidades que aprenden y reciben las tareas que mejor pueden realizar se convierten en más competentes en esas tareas. Esto es un modelo de especialización por aprendizaje competitivo. Además si las unidades están conectadas unas con otras de manera que los vecinos puedan aprender de las tareas de los vecinos más próximos el sistema lentamente va ordenando las unidades de manera que las unidades con habilidades para tareas similares acaben cerca unas de otras y las habilidades así van cambiado lenta y suavemente a través de todo sistema. Este es el principio general de los SOM. El sistema es llamado mapa y las tareas es lo que hay que imitar; por ejemplo representar las entradas lo mejor posible. Las representaciones son ordenadas según las similitudes de sus relaciones en un aprendizaje no supervisado. Este proceso hace al método SOM útil para organizar grandes colecciones de datos, incluidas colecciones de documentos.

¿Y ésto que es lo que es? Pues que en esencia, dado un conjunto de animales, por ejemplo, y una serie de atributos asociados a ellos (nº de patas, si tienen alas o no,…), si los pasamos por este algoritmo, al final obtendremos todos los animales agrupados o clasificados según sus características.

Para una información más detallada sobre la SOM, se puede consultar el siguiente vínculo: http://www.cis.hut.fi/research/som-research/

Volviendo al toolbox que pone nombre a este post, las funciones incluidas en él se pueden encontrar documentadas en la siguiente dirección: http://www.cis.hut.fi/projects/somtoolbox/package/docs2/somtoolbox.html

Y para usarlo con Matlab, basta con meterlo en la carpeta work del directorio donde se encuentra instalado éste.

Fuente (además de las mencionadas): “WEBSOM–self-organizing maps of document collections.” Neurocomputing, volume 21, pages 101-117.

Este tema que se va a explicar ahora se puede encontrar fácilmente en cualquier sitio. De hecho, al final se cita la fuente del mismo, aunque en este tutorial se usen imágenes propias.

Inicialmente se debe instalar el plugin para correr el servidor GlassFish. Para ello, se añade un nuevo servidor a través de las preferencias de Eclipse.

glassfish_addserver

Se pulsa Download additional adapters y se espera a que se cargue la lista de posibles servidores a instalar. En cuanto se vea GlassFish se selecciona y se prosigue con la instalación poniendo el directorio donde se descomprimió Glassfish (hay que indicar la carpeta glassfish dentro del directorio glassfishv3-prelude), la cual reiniciará Eclipse en cuanto haya terminado.

glassfish_addadditional

glassfish_installnew

Hecho esto ya se tiene el servidor listo para usar. Aunque ahora lo que habría que hacer es añadir la funcionalidad de Servicios Web, sin la cual no podemos continuar. Para ello, al iniciar el servidor GlassFish, se pulsa botón derecho sobre él y se va a GlassFish Update Center, lo cual abrirá en el navegador de Eclipse la página para actualizar el servidor.

glassfish_updatecenter

Una vez allí, en la pestaña de Complementos disponibles, se señala la funcionalidad metro entre las disponibles y se instala (esto puede que parezca que se ha atascado, ya que no hay barras de progreso, pero lo instala sin problemas ;) ).

Y ya está, la instalación ha concluido.

Fuente: https://glassfishplugins.dev.java.net/eclipse33/index.html

Existen dos maneras de instalar GlassFish. En nuestro caso, vamos a comentar la instalación mediante un archivo zip, ya que la otra es tan simple que no merece una entrada completa dedicada a él.

Hemos utilizado la versión 3 Prelude. La razón es debido a que utilizaremos conexión con .NET CF 3.5, aunque que alguien nos corrija si nos equivocamos, porque es posible que también se pueda usar la versión 2 sin problemas para esto.

Se descarga el zip de la página https://glassfish.dev.java.net/downloads/v3-prelude.html, seleccionando Zip File y, aunque esto depende del usuario, elegimos la opción Multilanguage (ML) para que la tengamos en Español.

Una vez descargada, la descompresión se realiza donde uno quiera, aunque nosotros lo hemos hecho en el directorio donde están instalados todos los programas (Archivos de Programa, pa‘ entendernos).

¿Y qué diferencia hay entre esta instalación y la de hacerlo con un ejecutable (.exe)? Pues, entre otras, la de que no te instala servicios chungos dentro del Sistema Operativo (SO) y que tardas mucho menos que darle al .exe y esperar, siendo más dinámico lo primero, vamos. Aunque es cierto que para ciertas configuraciones haya que tocar variables del sistema y tal, pero en nuestro caso no es necesario (en un principio).

Y ya está. Qué simpleza, qué elegancia, el GlassFish no me engaña :P

Y el ganador es… GlassFish!! Sí, es irónico, que un día apostemos por el veterano, y al día siguiente lo demos todo por el jovenzuelo.

Pero la verdad es que empezando con el código más a fondo nos hemos encontrado con que realizando un envío de imagen del servidor (Java) al cliente (.NET), al realizar un pequeño cambio en el que un método del servidor retornaba un array de bytes (la imagen serializada), el cliente no reconocía bien el tipo de ese nuevo valor de retorno. Es decir, obteníamos el siguiente error (pulsar para ver más grande):

error_axis2

Según leímos por ahí, Axis2 genera código para el WSDL un poco defectuoso y por esta razón, probamos GlassFish. La verdad es que su instalación en Eclipse es bastante sencilla y, salvo algún mínimo retoque, funcionó inmediatamente. Hecho esto instalamos Metro para los servicios web y creamos una pequeña aplicación.

Todo funcionó a la perfección.

Me parece que Tomcat ha perdido un asalto demasiado importante, con lo que GlassFish se sube al carro de nuestro proyecto.

En primer lugar se crea un proyecto nuevo para Smart Device utilizando, en nuestro caso, el Compact Framework 3.5 y como emulador Pocket PC 2003. Como dicen por ahí, una imagen (en este caso 2) vale más que mil palabras:

vs_newproject

vs_newprojectpda

En segundo lugar, abrimos el código del formulario y, aparte de añadir elementos a la interfaz, se debe hacer lo siguiente para acceder al WSDL:
Botón derecho sobre el proyecto-> Agregar referencia web.

referenciaweb

Se inserta la dirección donde se encuentra el WSDL. En nuestro caso, al usar Eclipse, al arrancar el servidor se puede acceder al WSDL a través del navegador incluído dentro del programa.

axis2_eclipse

Se copia la dirección y se pega en la susodicha ventana de Visual Studio. Si vamos a esa dirección, automáticamente recogerá el WSDL.

referenciaweb_encontrada

Si se quiere modificar la dirección en tiempo de ejecución, se debe usar el siguiente comando:

Dim mt As New localhost.MatlabTest
mt.Url = “http://192.168.2.101:8080/MatTest/services/MatlabTest”

Se debe modificar la IP poniendo la dirección numérica del servidor, ya que poniendo localhost desde la PDA no puede acceder a él. Por tanto, aunque es una solución provisional, sirve para ver el resultado.

La llamada a la función que tengamos implementada en el servidor es como si fuera una llamada local. En nuestro caso devuelve un array de bytes.

Dim ar As Byte()
ar = mt.evaluarFuncion(“surf(peaks)”)

Una vez hecho esto, la simple conexión debería ser satisfactoria ;)

omg

 

febrero 2012
L M X J V S D
« sep    
 12345
6789101112
13141516171819
20212223242526
272829  
Seguir

Get every new post delivered to your Inbox.